recipe-maintainers/cc-ci
0
0
Fork 0
Code Issues 1 Pull Requests 3 Actions Packages Projects Releases Wiki Activity
Files
369f4f486b58b8cd253be17fe7ebcfca0ae7ac79
cc-ci/STATUS-bsky.md
autonomic-bot cba53b69a4
All checks were successful
continuous-integration/drone/push Build is passing
Details
status(bsky): operator summary written (B9); journal: shot-phase N/A disposition superseded, no canonical to reseed (B8 complete)
2026-06-11 11:58:34 +00:00

7.4 KiB
Raw Blame History

STATUS — phase bsky (fix bluesky-pds recipe + screenshot)

Phase SSOT: /srv/cc-ci/cc-ci-plan/plan-phase-bsky-fix.md

Gate: M1 — CLAIMED, awaiting Adversary.

M1 claim — root cause + green fix PR + screenshot (2026-06-11T12:05Z)

WHAT

  1. Root cause proven with evidence (below).
  2. Fix PR open on the recipe mirror: recipe-maintainers/bluesky-pds PR #2, branch upgrade-0.3.0+v0.4.219, head f7b6c8df — 2-line compose.yml diff (image ghcr.io/bluesky-social/pds:0.4 → 0.4.219; version label 0.2.0+v0.4 → 0.3.0+v0.4.219). UNMERGED (operator merges).
  3. !testme on the PR green through the full lifecycle via the real drone path: run 427 = level 5 — install/backup_restore/functional/lint all PASS, upgrade = DECLARED intentional skip (justification below), clean_teardown, no_secret_leak.
  4. Screenshot captured on that PR run and visually verified by me: the genuine PDS HTTP landing page (ASCII Bluesky logo, "This is an AT Protocol Personal Data Server", /xrpc/ pointer, upstream links) — real, representative, credential-free. No SCREENSHOT hook needed.

Root cause

The recipe pins MOVING tag ghcr.io/bluesky-social/pds:0.4 and overrides the entrypoint with a script ending exec node --enable-source-maps index.js (relative to WORKDIR /app). Upstream now publishes main-branch builds to :0.4 (== latest, manifest sha256:871194d2…, created 2026-05-30): @atproto/pds 0.5.1, Node v24.15.0, service restructured to /app/index.ts (CMD node --enable-source-maps index.ts; no index.js) → crash-loop Cannot find module '/app/index.js'. Exact tag 0.4.219 (newest released; ghcr digest sha256:e0b756701c92…) keeps the expected layout: Node v20.20.2, /app/index.js, dumb-init, CMD identical to the recipe's exec line.

HOW to verify root cause (any host with ssh cc-ci):

  • ssh cc-ci 'docker run --rm --entrypoint sh ghcr.io/bluesky-social/pds:0.4 -c "node --version; ls /app; grep @atproto/pds /app/package.json"' → EXPECTED v24.15.0; index.ts, NO index.js; "@atproto/pds": "0.5.1"
  • ssh cc-ci 'docker run --rm --entrypoint sh ghcr.io/bluesky-social/pds:0.4.219 -c "node --version; ls /app; grep @atproto/pds /app/package.json"' → EXPECTED v20.20.2; index.js present; "@atproto/pds": "0.4.219"
  • Upstream: Dockerfile@main = node:24.15-alpine3.23 + CMD index.ts; Dockerfile@v0.4.219 = node:20.20-alpine3.23 + CMD index.js. Registry doc: cc-ci-plan/upstream/bluesky-pds.md (plan repo f395247).

Upgrade-rung justification (the "justify status either way" item)

Published versions exist (0.1.1+v0.4, 0.2.0+v0.4) but BOTH pin the republished :0.4 → no published version can deploy as the upgrade base anymore (negative control: run 423, pre-harness-change, deployed base 0.1.1+v0.4 → identical MODULE_NOT_FOUND crash-loop, install=fail, PR head never reached; run-423 recipe checkout sat at tag 0.1.1+v0.4). Harness change e9745c8 (main): declaring the upgrade rung in recipe_meta EXPECTED_NA now also suppresses the base deploy — single deploy = the PR head; the upgrade tier records "skip"; derive_rungs classifies it the DECLARED intentional skip; reason fully visible in results.json skips.intentional and on the card. NOT a weakening: the rung is never reported pass; decision + re-enable path in machine-docs/DECISIONS.md (re-enable = UPGRADE_BASE_VERSION="0.3.0+v0.4.219" once merged+published). HOW: cc-ci-run -m pytest tests/unit/ -q from a cold clone of main on cc-ci → EXPECTED 253 passed (6 new in tests/unit/test_upgrade_base.py); nix develop .#lint -c bash scripts/lint.sh → EXPECTED lint: PASS.

Green-run evidence (run 427, drone path)

  • Trigger: PR #2 comment 14342 (!testme) → bridge log line [poll] triggered build 427 for bluesky-pds@f7b6c8df (PR #2, comment 14342); outcome line reflected outcome build 427 (bluesky-pds PR #2): success; PR result comment 14343 "✅ passed @ f7b6c8df".
  • HOW: ssh cc-ci 'cat /var/lib/cc-ci-runs/427/results.json' → EXPECTED level=5, ref=f7b6c8dfb81c, rungs install/backup_restore/functional/lint=pass + upgrade=skip, skips.intentional.upgrade=, flags clean_teardown+no_secret_leak true.
  • PR-head proof: run-427 per-run recipe checkout (/var/lib/cc-ci-runs/427/abra/recipes/bluesky-pds) at f7b6c8d chore: upgrade to 0.3.0+v0.4.219, compose.yml line 6 image=…:0.4.219.
  • Visuals: https://ci.commoninternet.net/runs/427/summary.png (card: level 5 of 5, all tiers PASS, upgrade INTENTIONAL SKIP + reason, screenshot thumb, clean-teardown + no-secret-leak chips), …/badge.svg ("cc-ci: level 5", green), …/screenshot.png (the PDS landing page described above).

WHERE

  • cc-ci main @ 72b3d6c (harness change e9745c8; journal/decisions 72b3d6c).
  • Mirror PR #2: recipe-maintainers/bluesky-pds#2 (head f7b6c8df; base main b2d86ef).
  • Runs: /var/lib/cc-ci-runs/427 (green, PR head), /var/lib/cc-ci-runs/423 (negative control, pre-change base trap).
  • Upstream registry: cc-ci-plan/upstream/bluesky-pds.md @ plan-repo f395247.

Operator summary

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. recipe-maintainers/bluesky-pds#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).