A pull request workflow should cancel older runs for the same PR when new commits are pushed. Which concurrency configuration is most appropriate?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Group by workflow plus ref so every new push to that PR lands in the same concurrency bucket, then cancel-in-progress: true retires the stale run. Unique run_id groups never cancel peers; strategy.fail-fast is matrix-only.
Full explanation below image
Full Explanation
For PR CI, engineers typically set concurrency.group to a stable key such as workflow name plus github.ref (the PR ref). With cancel-in-progress: true, a newer run in that group cancels the older in-progress run, saving minutes and reducing noisy outdated checks. Using github.run_id as the group makes every run unique, so cancellation never groups them. A single global group with cancel-in-progress: false serializes unrelated workflows without cancelling anything useful for PR churn. cancel-in-progress is not a strategy matrix key; fail-fast only controls whether remaining matrix legs are cancelled when one fails. For production deploy jobs you often keep cancel-in-progress: false so a release is not aborted mid-rollout—choose the flag based on whether interrupting work is safe.