Repository navigation
OpenConceptLab/ocl_online#306 | Build: a newer push cancels the older run, including one waiting at an approval gate - #940
Merged
Conversation
… run, including one waiting at an approval gate The release group already let only one run in progress, but a run parked at the rc, qa, staging or production gate held it, so the newer run stayed pending until someone cancelled the old one by hand. With cancel-in-progress, the newer push cancels it: the latest run is the only one left to approve. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GcLwjW3CmciUhMtBmiETb6
Member
Author
|
Codex review, pass 1 (codex-cli 0.162.1, commit 2fdbdd8) Verdict: clean. No findings. The prompt also asked Codex to check the description's claims about what changes for the approver; it reported none wrong. findings.json{
"reviewer": "codex-cli 0.162.1",
"perspective": "defects",
"mode": "full",
"commit": "2fdbdd8f",
"verdict": "clean",
"prior": [],
"findings": []
} |
Member
Author
|
Simplification review (fresh Claude subagent, commit 2fdbdd8) Verdict: clean. Nothing to cut: the diff is the one-line Loop summary: Codex pass 1 was clean, and the simplification review was clean, so there's nothing open. What remains is the ticket's "verified once" check, which can only run after merge: the next time two merges land within one run's lifetime, the older run should end Cancelled. It will be recorded on OpenConceptLab/ocl_online#306. simplify.json{"reviewer":"claude subagent","perspective":"simplify","mode":"full","commit":"2fdbdd8f","verdict":"clean","prior":[],"findings":[]} |
paynejd
marked this pull request as ready for review
October 13, 2026 20:37
snyaggarwal
approved these changes
Oct 14, 2026
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.
Tracked in OpenConceptLab/ocl_online#306 (scope S11: deploy workflows cancel superseded waiting runs automatically).
Why
Every push to
masterstarts a Build run that stops at four approval gates: rc, qa, staging and production. Therelease-${{ github.ref }}group allows one run in progress at a time, and a run parked at a gate counts as in progress. So when a newer merge lands, the older run keeps waiting and the newer one sits pending behind it until someone cancels the older run by hand. On Oct 6–7 a newer run waited about an hour this way. Approving the older run deploys an image older thanmaster.This PR changes one line:
cancel-in-progress: false→true.What changes for the approver
mastercancels the previous Build run wherever it is: tests, build, a gate, or a deploy job. Approve what's waiting. There's no older run to find and cancel.gh release delete <version> --cleanup-tag; that version was never deployed), then re-run the newer run's failed jobs.[skip ci], so they never start a run and never cancel one.Also, from reading
release_version.sh(not observed in a run): today, if a second merge lands before the first run's Release job, the first run publishes version N and bumpsmaster, and then the second run's Release fails, because its commit predates the bump and asks for N again. With this change the first run is cancelled before it releases, so only the newest run publishes N.How to verify (after merge)
There's nothing to test before merge: the workflow only runs on pushes to
master. The first time two merges land within one run's lifetime, check that the older run ends Cancelled, cancelled by the newer one in the same concurrency group, and that only the newer run reaches the gates. That's the ticket's "verified once" check, and it will be recorded on ocl_online#306.Other repos
oclweb3 and oclmap use the same group with
cancel-in-progress: falseand also run on every push. The repos whose release workflows are started by hand use it too. The full list is on ocl_online#306. Their PRs follow once this one is settled.🤖 Generated with Claude Code
https://claude.ai/code/session_01GcLwjW3CmciUhMtBmiETb6