The problem
Only 19 of 54 workflows across the org declare a concurrency: group:
smrt 4/13
sdk 3/16
happyvertical.com 3/7
pdf 3/5
iac 6/13
Without one, pushing to a pull request queues a complete duplicate set of jobs while the previous set is still holding runner slots. Nothing cancels the superseded run.
That is expensive against a pool of roughly 12 slots where 77% of wall time is already queue wait (17.7h waiting against 5.2h running across 180 sampled jobs). Every superseded run is capacity spent producing a result nobody will read, and it delays the run that matters.
Proposal
Add to every pull-request-triggered workflow:
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: trueDeliberate exclusions, which should be stated rather than assumed:
- Publish / release workflows — cancelling a partially completed publish can leave a registry or tag half-written. Use
cancel-in-progress: false so runs queue instead of cancelling.
- Deploy workflows — same reasoning; a cancelled deploy is worse than a slow one.
main/master push triggers — cancelling these loses the record for a commit that is already merged.
So the change is not a blanket sweep: pull-request validation cancels, anything that mutates the outside world queues.
Scope
One pull request per repository — smrt, sdk, happyvertical.com, pdf, iac. Each is patch-class and the workflows within a repo can bundle.
Validation
Push twice in quick succession to a scratch branch and confirm the first run is cancelled rather than both completing. A concurrency block that is present but scoped wrongly — for example keyed on github.sha, which is unique per push — cancels nothing while looking correct.
The problem
Only 19 of 54 workflows across the org declare a
concurrency:group:Without one, pushing to a pull request queues a complete duplicate set of jobs while the previous set is still holding runner slots. Nothing cancels the superseded run.
That is expensive against a pool of roughly 12 slots where 77% of wall time is already queue wait (17.7h waiting against 5.2h running across 180 sampled jobs). Every superseded run is capacity spent producing a result nobody will read, and it delays the run that matters.
Proposal
Add to every pull-request-triggered workflow:
Deliberate exclusions, which should be stated rather than assumed:
cancel-in-progress: falseso runs queue instead of cancelling.main/masterpush triggers — cancelling these loses the record for a commit that is already merged.So the change is not a blanket sweep: pull-request validation cancels, anything that mutates the outside world queues.
Scope
One pull request per repository —
smrt,sdk,happyvertical.com,pdf,iac. Each is patch-class and the workflows within a repo can bundle.Validation
Push twice in quick succession to a scratch branch and confirm the first run is cancelled rather than both completing. A
concurrencyblock that is present but scoped wrongly — for example keyed ongithub.sha, which is unique per push — cancels nothing while looking correct.