You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ci(repo): keep production releases running when main moves - #10617
A merge to main during a production release cancels the release, even in the middle of changeset publish. On Nov 3 that left run 41703272864 half published. For about 22 minutes, @clerk/clerk-js@6.42.2, @clerk/backend@3.26.6 and @clerk/expo@4.15.0 were on latest and depended on a @clerk/shared@4.44.0 that wasn't on npm yet.
GitHub uses the cancel-in-progress value of the newer run. Canary pushes now set it to false, so they wait for a running release instead of cancelling it. Version packages pushes and snapshot runs still cancel. A newer canary still replaces an older pending one, so a burst of merges queues one canary, not one per merge.
The release script now runs git push origin --tags instead of git push --follow-tags. --follow-tags also pushes main, which has no new commits after publish and gets rejected if anyone merged during the release. The cancellation used to hide that. With the concurrency change, the Oct 13 and Nov 3 releases would both have published and then failed here. The tags still go up before scripts/wait-for-packages-on-npm.mjs runs, so a timeout there doesn't lose them.
🤖 Generated with Claude under Rob's supervision.
Checklist
pnpm test runs as expected.
pnpm build runs as expected.
(If applicable) JSDoc comments have been added or updated for any package exports
A merge to main during a production release cancelled the run in the
middle of changeset publish, which left half the packages on npm.
Canary pushes now queue behind an in-progress run instead of
cancelling it. Version packages pushes and snapshot runs still cancel.
The release script no longer pushes main after publish. changeset
publish creates tags only, and changesets/action pushes each tag
itself. The push failed with a non-fast-forward error on any re-run
after main had moved.
No actionable comments were generated in the recent review.
Walkthrough
The release workflow now cancels an in-progress run only for non-push events or pushes whose head commit message contains Version packages. The release script now pushes tags with git push origin --tags. The changeset file contains empty YAML frontmatter and no release-note body.
No concrete merge-blocking risk was established in the release workflow or tag-publishing changes.
Pre-merge checks: 4
Check name
Status
Explanation
Title check
The title clearly identifies the main change: preventing in-progress production releases from being canceled when main moves.
Description check
The description directly explains the release cancellation problem and the workflow and tag-push changes that address it.
Linked Issues check
Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check
Check skipped because no linked issues were found for this pull request.
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Warning
Linked repositories: Some configured repositories could not be included in this review. Cross-repository analysis may be incomplete. Please check linked-repository access and settings.
CodeRabbit Verify
Run CodeRabbit Verify to test the changes in this pull request.
Included review availability: This review used your included allowance. 9 included reviews remain after this review. Your included PR review attempts over the past 7 days set your current allowance at 10 reviews per hour.
The npm wait runs after the tag push and can time out. changesets/action
pushes tags only when the whole release command succeeds, so dropping the
push would lose the tags in that case.
Evaluated with GitHub's expression library: a canary push to main now gets cancel-in-progress false (was true), while Version packages pushes, !snapshot comments and snapshot dispatches still get true. Not run on GitHub itself.
Merge-base
This PR 9ae5e6b9
Also checked · 1 match · 1 not run
Newer canary replaces older pending one · Skipped Tags pushed when main moved mid-release
Proof on 9ae5e6b9 · Did Proof get it right? Yes · No
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
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.
Description
A merge to
mainduring a production release cancels the release, even in the middle ofchangeset publish. On Nov 3 that left run 41703272864 half published. For about 22 minutes,@clerk/clerk-js@6.42.2,@clerk/backend@3.26.6and@clerk/expo@4.15.0were onlatestand depended on a@clerk/shared@4.44.0that wasn't on npm yet.GitHub uses the
cancel-in-progressvalue of the newer run. Canary pushes now set it tofalse, so they wait for a running release instead of cancelling it.Version packagespushes and snapshot runs still cancel. A newer canary still replaces an older pending one, so a burst of merges queues one canary, not one per merge.The
releasescript now runsgit push origin --tagsinstead ofgit push --follow-tags.--follow-tagsalso pushesmain, which has no new commits after publish and gets rejected if anyone merged during the release. The cancellation used to hide that. With the concurrency change, the Oct 13 and Nov 3 releases would both have published and then failed here. The tags still go up beforescripts/wait-for-packages-on-npm.mjsruns, so a timeout there doesn't lose them.🤖 Generated with Claude under Rob's supervision.
Checklist
pnpm testruns as expected.pnpm buildruns as expected.Type of change