CI runs once, and never cancels a merge to main - #7
Merged
Conversation
Two problems, both visible as a column of `cancelled` in the run list — 14 of the last 40 runs here. **Every push ran the gate twice.** `push:` with no filter fires alongside `pull_request:` for any branch with a pull request open, and the concurrency group cleaned that up after the fact: same key for both events, cancel-in-progress. It worked and it cost a run each time, because both started and took a runner before one was killed. On a self-hosted runner it costs more than the runner: two runs of this gate install the same release and restart the same containerd, so the loser does not merely stop, it fails during setup — and the failure is about a machine two runs were fighting over rather than about the change. A branch is tested through its pull request now, and main when something lands on it. **A merge to main could be cancelled.** cancel-in-progress applied there too, so two merges landing close together left the first with no verdict. That already happened, to the merge of #3. Two merges are two things to verify, not one, and a gate whose own rule is that a skipped lane counts as a failure should not quietly drop a whole run. What is given up: a branch with no pull request open is not tested. That is what opening one is for. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019GHRRFvbnZi5q3KSTvyW5a
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.
Two problems, both showing up as the column of
cancelledruns — 14 of the last 40 runs in this repository.Every push ran the gate twice
push:with no filter fires alongsidepull_request:for any branch that has a pull request open, so every push started two identical runs. The concurrency group cleaned that up after the fact: same key for both events,cancel-in-progress: true. It worked, and it cost a run every time — both started, both took a runner, one was killed.On a self-hosted runner it costs more than the runner. Two runs of this gate install the same release and restart the same containerd, so the loser does not merely stop: it fails during setup, and the failure is about a machine two runs were fighting over rather than about the change. (spinbox's workflow has the same shape and its comment records exactly that symptom.)
A branch is tested through its pull request now; main is tested when something lands on it.
A merge to main could be cancelled
cancel-in-progressapplied on main too, so two merges landing close together left the first with no verdict at all. That is not hypothetical — it happened to the merge of #3. Two merges are two things to verify, not one, and a gate whose own rule is that a skipped lane counts as a failure should not quietly drop an entire run.What is given up
A branch with no pull request open is not tested. That is what opening one is for.
Note
spinbox has the identical
on:/concurrency:pair and the same two problems. Not touched here — say the word and it gets the same change.🤖 Generated with Claude Code
https://claude.ai/code/session_019GHRRFvbnZi5q3KSTvyW5a