perf(ci): cancel superseded Claude review runs (#36962) - #36963
Merged
Conversation
The four Claude workflows fire on pull_request [opened, synchronize] and none declared a concurrency group, so every push launched four more jobs while the previous four kept reviewing a commit nobody will merge. Observed directly: a force-push at 18:48 started a fresh set while the 18:46 set was still running on the same branch. These are not on the critical path -- standalone workflows, not required status checks, no merge_group trigger -- so this is not about latency. It is runner contention: measured aggregate queue on a PR run reaches 271 job-minutes with individual jobs waiting 20m, and superseded jobs hold slots the rest of the pipeline is waiting for. The orchestrator needs a different group because it also fires on issue_comment and pull_request_review_comment. Keying on comment.id first keeps each comment run in its own group, so a second @claude comment cannot cancel an in-flight interactive reply; run_id as the final fallback leaves manual workflow_dispatch runs alone. Only push-triggered runs supersede each other. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014a2iJy9JXRBSVdKBbmoZ2S
erickgonzalez
approved these changes
Aug 7, 2026
sfreudenthaler
approved these changes
Aug 7, 2026
sfreudenthaler
left a comment
Member
There was a problem hiding this comment.
These are good, should push them upstream to dotcms/ai-workflows docs and/or templates
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.
Closes #36962.
What
Adds a
concurrencygroup withcancel-in-progress: trueto the four Claude AI workflows, matching the patterncicd_1-pr.yml:36already uses.Why
All four fire on
pull_request: [opened, synchronize]and none declared a concurrency group. Every push to a PR launches four more jobs while the previous four keep reviewing a commit nobody will merge.Observed directly while working on #36961 — a force-push at 18:48 started a new set while the 18:46 set was still in progress on the same branch:
This is contention, not latency
Worth being precise, because it changes what the fix is worth. These workflows are not on the critical path:
cicd_1-pr.ymlmainareFinalize / Final StatusandInitialize / Initialize— no Claude workflow is required, none can block a mergemerge_grouptrigger, so they never run in the merge queueSo this does not shorten the pipeline directly. It stops superseded jobs from holding runner slots the rest of the pipeline is queueing for. Measured aggregate queue on a PR run reaches 271 job-minutes, with individual jobs waiting 20m, so that contention inflates wall clock indirectly.
The orchestrator is deliberately different
ai_claude-orchestratoralso fires onissue_commentandpull_request_review_comment. A naivecancel-in-progressthere would kill an in-flight interactive@claudereply the moment a second comment arrived.The fallback chain avoids that:
github.event.comment.idgithub.event.pull_request.numbergithub.run_idworkflow_dispatchOnly push-triggered runs supersede each other.
Risk
Low. Worst case a review is cancelled and the push that cancelled it triggers a fresh one, which is the intent. No behaviour change for comment-driven or manual runs.
🤖 Generated with Claude Code
https://claude.ai/code/session_014a2iJy9JXRBSVdKBbmoZ2S
This PR fixes: #36962