ci(publish): fail-fast preflight gate on release tag/version mismatch#319
Merged
Conversation
The 1.0.0-rc.3 publish failed at the very end with `release tag v1.0.0-rc.3 != package version 1.0.0-rc.2`: the release tag had been cut on main's pre-merge tip (rc.2) instead of the merged bump commit (rc.3). The existing `check-release --release-tag` caught it — but only inside publish-npm, after the ~15-min verify + e2e gates had already run. Add a `preflight` job that runs first and gates verify/e2e (and thus publish): it compares the release tag to the version in the tagged commit and fails in seconds with a fix-it message when they diverge. The publish job keeps the authoritative `--release-tag` check as defense-in-depth. Docs: note the preflight gate in RELEASING.md's CI section. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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
1 participant
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.
Why
The
1.0.0-rc.3publish run failed with:#318 merged fine (main → rc.3 at
116efe7), but the release tagv1.0.0-rc.3was cut on the pre-merge commit9de6ee2(still rc.2). The guardrail caught it correctly — but only at the publish step, after the full ~15-min verify + e2e gates had already run.What
preflightjob, first in the pipeline, thatverifyande2e(and transitivelypublish-npm) depend on. It comparesgithub.event.release.tag_nameto the version in the tagged commit and fails in seconds with an actionable message when they diverge — no install, no build.publish-npmkeeps the authoritativecheck-release --release-tagas defense-in-depth.Verification
preflight → {verify, e2e} → publish-npm.prettier --check✓Note
This prevents recurrence. To actually ship rc.3, the tag must be re-pointed to the bumped commit and the release re-fired (the 21 new packages are now on npm at rc.2, so the brand-new-name bootstrap blocker is cleared — but their Trusted Publishers must be attached for the OIDC publish to authenticate).
🤖 Generated with Claude Code