fix(ci): stop a superseded run from deciding the release - #16
Merged
Conversation
The changepacks job runs after verify, which takes about ten minutes, so by the time it evaluates, main may already be several commits further on and it judges a state that no longer exists. On 2026-09-08 three merges landed inside one such window. Each stale run opened a fresh Update Versions pull request instead of releasing, all three were merged, and the workspace went 0.2.1 -> 0.3.0 -> 0.3.1 while the newest release stayed 0.2.1. Nothing was tagged, and re-running could not recover it: the action only cuts a release in the run that actually consumes the changepacks, and by then there were none left. A version that moved without releasing cannot be un-moved. The job now compares its own commit with the tip of main and stands down when it has been replaced, leaving the decision to the run for the commit that replaced it.
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.
This also carries the changepack that gets the release unstuck.
What happened
The \changepacks\ job runs after \�erify\ (~10 min), so by the time it evaluates, main may already be several commits further on — and it judges a state that no longer exists.
On 2026-09-08 three merges landed inside one such window. Each stale run opened a fresh Update Versions PR instead of releasing (#11, #14, #15), all three were merged, and the workspace went 0.2.1 → 0.3.0 → 0.3.1 while the newest release stayed 0.2.1. No tag, no release.
Re-running the last workflow does not recover it: the action only cuts a release in the run that actually consumes changepacks, and by then there were none left. A version that moved without releasing cannot be un-moved — so 0.3.0 and 0.3.1 stay phantom, and the next real release is 0.3.2.
The guard
The job compares its own commit with the tip of main and stands down when it has been replaced, leaving the decision to the run for the commit that replaced it. A superseded run can no longer open a stale PR or consume changepacks against a state that has moved.
Getting the release out
Merging this puts exactly one changepack on main, which produces exactly one Update Versions PR. Merge that one and wait for its run to finish before merging anything else — that run is the one that tags, drafts, builds, bundles and publishes.