Skip to content

OpenConceptLab/ocl_online#306 | Build: a newer push cancels the older run, including one waiting at an approval gate - #940

Merged
snyaggarwal merged 1 commit into
masterfrom
ocl_online/306-cancel-superseded-runs
Oct 14, 2026
Merged

snyaggarwal merged 1 commit into
masterfrom
ocl_online/306-cancel-superseded-runs

Conversation

@paynejd

@paynejd paynejd commented Oct 13, 2026

Copy link
Copy Markdown
Member

Tracked in OpenConceptLab/ocl_online#306 (scope S11: deploy workflows cancel superseded waiting runs automatically).

Why

Every push to master starts a Build run that stops at four approval gates: rc, qa, staging and production. The release-${{ 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 than master.

This PR changes one line: cancel-in-progress: false → true.

What changes for the approver

  • Only the newest run is ever waiting for you. A push to master cancels 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.
  • A merge during a running deploy job cancels that job partway. Each "Deploy to …" job updates about nine services one after another (about 4 minutes for production). Services the cancelled job hadn't reached keep their previous image until you approve the newer run through that environment. Avoid merging while a deploy job runs. If it happens, approve the newer run through promptly.
  • A merge during the Release job (about 2 minutes after you approve rc) can stop it after the GitHub release is published but before the version bump is pushed. The newer run's Release step then fails because that tag already exists. To recover, delete the orphaned release and its tag (gh release delete <version> --cleanup-tag; that version was never deployed), then re-run the newer run's failed jobs.
  • Don't re-run an old run. A re-run joins the same group, so it cancels the newer run, and if you approve it, it deploys the older image.
  • Version-bump commits are [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 bumps master, 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: false and 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

… 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
@paynejd

paynejd commented Oct 13, 2026

Copy link
Copy Markdown
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": []
}

@paynejd

paynejd commented Oct 13, 2026

Copy link
Copy Markdown
Member Author

Simplification review (fresh Claude subagent, commit 2fdbdd8)

Verdict: clean. Nothing to cut: the diff is the one-line cancel-in-progress change and its three-line comment.

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
paynejd marked this pull request as ready for review October 13, 2026 20:37
@paynejd
paynejd requested a review from snyaggarwal October 14, 2026 01:10
@snyaggarwal
snyaggarwal merged commit f698f4c into master Oct 14, 2026
3 checks passed
@snyaggarwal
snyaggarwal deleted the ocl_online/306-cancel-superseded-runs branch October 14, 2026 02:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants