From cba53b69a4b813fa11f0fc6c6d827c7c10d13205 Mon Sep 17 00:00:00 2001 From: autonomic-bot Date: Thu, 11 Jun 2026 11:58:34 +0000 Subject: [PATCH] status(bsky): operator summary written (B9); journal: shot-phase N/A disposition superseded, no canonical to reseed (B8 complete) --- JOURNAL-bsky.md | 18 ++++++++++++++++++ STATUS-bsky.md | 34 +++++++++++++++++++++++++++++++++- 2 files changed, 51 insertions(+), 1 deletion(-) diff --git a/JOURNAL-bsky.md b/JOURNAL-bsky.md index 1b78113..0f2f657 100644 --- a/JOURNAL-bsky.md +++ b/JOURNAL-bsky.md @@ -84,3 +84,21 @@ butterfly, "This is an AT Protocol Personal Data Server", /xrpc/ pointer) — ex default capture the phase plan predicted would work once deploy works; no hook needed. Card (summary.png): 5/5, upgrade shown INTENTIONAL SKIP with reason; badge "level 5" green. M1 claimed in STATUS-bsky.md. + +## 2026-06-11T12:15Z — records closed (B8) + operator summary drafted (B9) + +DEFERRED bluesky entry marked RESOLVED with pointers (f150012) — covers BOTH the re-pin +follow-up and the rcust M2 baseline-exclusion note. + +**Shot-phase N/A disposition update (supersedes the deploy-gated classification):** +the shot phase classified bluesky-pds's screenshot "deploy-gated N/A — never capturable +because the app never comes up". With the PR#2 fix deployed (run 427, PR head), the +DEFAULT landing-page capture works exactly as the phase plan predicted: a real, +representative, credential-free PDS landing page (ASCII butterfly + "This is an AT +Protocol Personal Data Server" + /xrpc/ pointer). No SCREENSHOT hook was needed. The +N/A stands for HISTORICAL runs only; post-merge, bluesky-pds screenshots like any other +recipe. + +Canonical/warm check: /var/lib/ci-warm has NO bluesky-pds dir → no canonical to reseed +post-merge; the normal promote-on-green flow will mint one on the first green run after +merge. Operator summary written to STATUS-bsky.md (B9). diff --git a/STATUS-bsky.md b/STATUS-bsky.md index 958d45f..43f97ef 100644 --- a/STATUS-bsky.md +++ b/STATUS-bsky.md @@ -85,4 +85,36 @@ EXPECTED 253 passed (6 new in tests/unit/test_upgrade_base.py); ## Operator summary -(to be completed at M2) +**What was wrong.** bluesky-pds could not deploy at all: the app crash-looped +`Cannot find module '/app/index.js'`. The recipe pins the MOVING image tag +`ghcr.io/bluesky-social/pds:0.4`, and upstream now republishes that tag with main-branch +builds (currently @atproto/pds 0.5.1 on Node 24, where the service entrypoint moved to +`/app/index.ts` — `index.js` no longer exists). The recipe's entrypoint override +(`exec node --enable-source-maps index.js`) can no longer resolve. This also silently +broke BOTH previously published recipe versions (0.1.1+v0.4, 0.2.0+v0.4 — same moving +pin), so no historical version can deploy anymore either. + +**What the PR changes.** https://git.autonomic.zone/recipe-maintainers/bluesky-pds/pulls/2 +(branch `upgrade-0.3.0+v0.4.219`, head f7b6c8df), a 2-line compose.yml diff: pin the exact +released tag `0.4.219` (newest released; classic Node 20 / index.js layout the recipe's +entrypoint expects) and bump the version label to `0.3.0+v0.4.219`. Why not 0.5.1: it has +no release tag (only the moving :0.4/latest + sha- tags from main) and needs an entrypoint +migration; do that as a proper upgrade when upstream cuts a 0.5.x release tag (notes in +cc-ci-plan/upstream/bluesky-pds.md). Proven at PR head via real drone CI: run 427 = +**level 5** (install, backup/restore, functional, lint PASS; screenshot = real PDS landing +page). The upgrade rung is a DECLARED intentional skip — there is no deployable published +base to upgrade FROM (see above); declaration + reason in tests/bluesky-pds/recipe_meta.py. + +**What to do post-merge.** +1. Merge PR #2 (your call, as with immich PR#2 / plausible PR#3 — all left open). +2. Publish the version per recipe convention (annotated tag `0.3.0+v0.4.219` / + `abra recipe release`) so `abra recipe versions` lists a deployable version again. +3. After the tag is published: in cc-ci `tests/bluesky-pds/recipe_meta.py`, DROP the + `EXPECTED_NA["upgrade"]` declaration and set + `UPGRADE_BASE_VERSION = "0.3.0+v0.4.219"` — the upgrade rung then re-activates from + the first deployable base (the older broken tags must never be auto-picked as base). +4. Canonical/warm: nothing to reseed — bluesky-pds has no canonical + (/var/lib/ci-warm has no entry); the normal promote-on-green flow mints one on the + first green run post-merge. +5. Never re-pin this recipe to `:0.4`/`latest` — upstream demonstrably republishes the + minor tag (registry notes: cc-ci-plan/upstream/bluesky-pds.md).