.github/workflows/api-pr.yaml has no concurrency group. Every push to a pull request starts a full run, and all earlier runs for the same pull request keep going to completion even though nobody will look at them again.
This is pre-existing, but #4385 makes it expensive. The new Coverage ratchet job runs the whole suite unsharded under full TypeScript compilation — around 15 minutes. With the draft-first convention, a branch that gets three quick corrections burns three of those runs, of which only the last is of any interest.
Proposal
concurrency:
group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
cancel-in-progress: true
One thing to check first
Once any of these jobs becomes a required status check (#4386), confirm how a cancelled run is treated. A cancelled check is not a passing check, and the replacement run has to be the one the ruleset evaluates. Worth verifying on a throwaway pull request before relying on it, rather than discovering it on a branch someone is waiting to merge.
Related: #4385, #4386
.github/workflows/api-pr.yamlhas noconcurrencygroup. Every push to a pull request starts a full run, and all earlier runs for the same pull request keep going to completion even though nobody will look at them again.This is pre-existing, but #4385 makes it expensive. The new
Coverage ratchetjob runs the whole suite unsharded under full TypeScript compilation — around 15 minutes. With the draft-first convention, a branch that gets three quick corrections burns three of those runs, of which only the last is of any interest.Proposal
One thing to check first
Once any of these jobs becomes a required status check (#4386), confirm how a cancelled run is treated. A cancelled check is not a passing check, and the replacement run has to be the one the ruleset evaluates. Worth verifying on a throwaway pull request before relying on it, rather than discovering it on a branch someone is waiting to merge.
Related: #4385, #4386