fix(release): publish the GitHub Release only after verified R2 staging - #497
Merged
Merged
Conversation
Fixes #293. The workflow published the public GitHub Release before the immutable R2 objects existed, so a failed R2 stage could leave a complete-looking canonical release with no distribution artifacts. publish-r2.sh now has objects|pointer|all phases: the immutable versioned objects (and stable installer scripts) are uploaded and publicly verified in `objects`; the channel's version pointer advances in `pointer`. The publish-r2 job runs objects for both channels right after artifact verification, and nightly's pointer inside the same job since nightlies have no GitHub Release. publish-release needs publish-r2, so an R2 upload or verification failure leaves no newly public release. A new advance-latest job runs the stable pointer after the canonical release is public, so wright/latest/version never points at a version lacking one. publish-tap already waits on publish-release and keeps that ordering. verify-dist.py now parses the workflow's needs edges and asserts this promotion order, the independent release-flow check #293 asks for.
…env checks Review follow-up on the #293 reorder. verify-dist.py's workflow parser now strips comments before reading needs edges and step bodies, bounds the jobs scan at the next top-level key, asserts publish-r2 needs release-assets, requires the literal stable/nightly channel gates, and checks the pointer step runs after objects inside publish-r2 — previously a reordered or wrong-polarity step could pass the guard. publish-r2.sh again requires R2_INSTALLER_PUBLIC_BASE_URL up front for stable instead of after the uploads. docs/release.md notes that a promotion cancelled after R2 staging can leave verified immutable objects inert, and ADR-0019 no longer describes the superseded ordering.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #293.
What changed
publish-r2.shnow has three phases —objects(immutable versioned uploads + public verification, plus the stable installer scripts),pointer(the channel'swright/<latest|nightly>/versionwrite + public verify), andall(the previous combined behavior). The release workflow uses them to invert the old order:publish-r2runsobjectsright afterrelease-assets— before the GitHub Release — so an R2 upload or public-verification failure blocks promotion.publish-releaseneedspublish-r2; a failed/skipped R2 stage leaves no newly public release.advance-latestjob runspointeronly afterpublish-releasesucceeds, sowright/latest/versionnever points at a version lacking a canonical public release.objectsthenpointerinsidepublish-r2.verify-dist.pygainsrelease_promotion_order(): it parses the workflow'sneedsedges and step bodies (comments stripped, job bodies bounded to the jobs section) and fails unless publish-r2 needs release-assets, publish-release needs publish-r2 (and publish-r2 doesn't need it back), the objects step precedes any pointer step, the in-job pointer is gated onchannel == 'nightly', advance-latest is stable-gated and runspointer, and publish-tap still waits on publish-release.docs/release.mdand ADR-0019 now describe the new order, including that a promotion cancelled after staging can leave verified immutable R2 objects inert (pointer never advanced; retries byte-check them).Acceptance criteria mapping
verified-release-assets— no second build/packaging path.publish-release → publish-r2edge (job-levelneedsgating, noalways()bypass).advance-latestneedspublish-release.release_promotion_order()runs insideverify-dist(CI dist-validation leg).Verification
python3 scripts/verify-dist.py— all checks pass, including the new ordering guard.bash -n scripts/publish-r2.sh.aws/curlruns:objectspublishes 8 artifacts (+2 installer scripts for stable) with zero pointer writes;pointerwrites onlywright/<latest|nightly>/versionand needs noARTIFACTS_DIR;allpreserves the old single-invocation flow; bogus phase exits 2; missing env vars fail fast.