publish: next lane builds gateway images only — no web/appservice next images, so no sha-parity set exists for next-lane containerized deploys #1406

Open
opened 2026-08-24 23:44:50 +00:00 by ops-deploy-01 · 0 comments
Member

DESIGN GAP, not a broken lane (framing corrected by fred; verified against origin/next .woodpecker/publish.yml).

Measured config: the image_build_when anchor (lines ~41-51) includes event: [push, manual] branch: next, and build-gateway (line 273) uses it — so next-lane pushes publish gateway:sha-<7hex>. But build-appservice (line 309) and build-web (line 336) use the main_image_build_when anchor, whose entries are tag + main ONLY — no next entry at all.

Measured registry consequence: gateway has 26 sha tags (newest sha-d7b1dd9, 2026-08-24T22:21Z, from the next lane); web and appservice have EXACTLY ONE sha tag each — sha-712c770, built 2026-07-26T08:34Z, which is simply the last MAIN build (712c770 = main tip's build base per the ci-base lock-tag comment) and an ancestor of the next tip.

Impact: a next-lane containerized deployment cannot pin a sha-parity set: the only combinable pairing is gateway@next-sha + web/appservice@month-old-main-sha, whose protocol compatibility is unmeasured. Consumer that hit it: P3 dark deploy on web1 (usc/infrastructure #272) — the deploy-side preflight's tag-existence check flagged web:sha-d7b1dd9 as 404 before any image pull (constraint: verify pins by registry query, not assumption).

Ask: either extend the next publish to web/appservice (add the next entry to main_image_build_when, or migrate those steps onto image_build_when with sha-only destinations like gateway's next branch guard), or document the supported pairing explicitly. Tag: T63 batch 2 context. Found by ops-deploy-01 during P3; consumers of a fix: #272 (dark deploy), the future containerized flip.

DESIGN GAP, not a broken lane (framing corrected by fred; verified against origin/next .woodpecker/publish.yml). **Measured config:** the `image_build_when` anchor (lines ~41-51) includes `event: [push, manual] branch: next`, and build-gateway (line 273) uses it — so next-lane pushes publish gateway:`sha-<7hex>`. But build-appservice (line 309) and build-web (line 336) use the `main_image_build_when` anchor, whose entries are tag + main ONLY — no next entry at all. **Measured registry consequence:** gateway has 26 sha tags (newest sha-d7b1dd9, 2026-08-24T22:21Z, from the next lane); web and appservice have EXACTLY ONE sha tag each — sha-712c770, built 2026-07-26T08:34Z, which is simply the last MAIN build (712c770 = main tip's build base per the ci-base lock-tag comment) and an ancestor of the next tip. **Impact:** a next-lane containerized deployment cannot pin a sha-parity set: the only combinable pairing is gateway@next-sha + web/appservice@month-old-main-sha, whose protocol compatibility is unmeasured. Consumer that hit it: P3 dark deploy on web1 (usc/infrastructure #272) — the deploy-side preflight's tag-existence check flagged web:sha-d7b1dd9 as 404 before any image pull (constraint: verify pins by registry query, not assumption). **Ask:** either extend the next publish to web/appservice (add the next entry to main_image_build_when, or migrate those steps onto image_build_when with sha-only destinations like gateway's next branch guard), or document the supported pairing explicitly. Tag: T63 batch 2 context. Found by ops-deploy-01 during P3; consumers of a fix: #272 (dark deploy), the future containerized flip.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1406