fix(ci): a commit must not cancel another commit's run - #89
Merged
Conversation
The concurrency group was keyed by branch with cancel-in-progress, so a newer merge cancels an older commit's CI — and every deploy path keys off that run. One that waits for CI to pass on the commit finds a cancelled run and stops. One chained on workflow_run sees conclusion=cancelled and skips. auto-merge also re-arms CI with a dispatch, and under one group-per-branch that dispatch cancels the push run for the SAME commit. Measured across the fleet on 2026-09-11: 28 of 39 ci.yml files had this shape. It broke two repos that day, in the two ways it can break. fleetcrown failed silently — Deploy skipped, four merges sat on main with every check green and nothing red while the box served the previous build, each needing a hand-dispatched deploy. hirnli failed loudly, erroring at its wait-for-CI step, which is the better outcome because somebody sees it. Keying main per commit lets both runs finish, so whatever the deploy path looks for is there. Branch behaviour is unchanged: the newest push is still the only one that matters there. The templates this was copied from are fixed in bitbaum/fleet#53, which also adds a ci-strands-commits rule to the hygiene audit so the remaining repos are found by a sweep rather than by an outage. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018Z7YRpgsEtNjRqr1usHMQY
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
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.
The concurrency group was keyed by branch with
cancel-in-progress: true, so a newer merge cancels an older commit's CI run — and every deploy path keys off that run:workflow_runseesconclusion: cancelledand skips.auto-merge also re-arms CI with a dispatch, and under one group-per-branch that dispatch cancels the push run for the same commit.
It is not theoretical
Measured across the fleet on 2026-09-11: 28 of 39
ci.ymlfiles had this shape. It broke two repos that day, in the two ways it can break.The change
Main is keyed per commit, so both runs finish and whatever the deploy path looks for is there. Branch behaviour is unchanged — the newest push is still the only one that matters there.
Upstream: bitbaum/fleet#53 fixes the templates this was copied from and adds a
ci-strands-commitsrule to the hygiene audit, so the remaining repos are found by a sweep rather than by an outage.Workflow-only change: YAML parses and the jobs are intact. This PR's own CI run exercises the branch arm of the new expression.
🤖 Generated with Claude Code
https://claude.ai/code/session_018Z7YRpgsEtNjRqr1usHMQY