Workflows and jobs without concurrency controls can pile up redundant, overlapping runs that waste CI/CD compute, lengthen queue times, and delay feedback when commits or pull request updates land in quick succession. Set the concurrency property to an object with a group and an explicit cancel-in-progress value, so the behavior for overlapping runs is a deliberate choice rather than an implicit default.
Use cancel-in-progress: true where only the latest commit matters, such as pull request builds, tests, and linting. GitHub then cancels the in-progress run for the same concurrency group instead of running duplicates. Use cancel-in-progress: false for workflows that must not be interrupted mid-flight, such as deployments and release publishing, where new runs should queue behind the current one. This rule accepts either value.
The rule flags workflows or jobs that omit concurrency entirely, set it to a bare string, or provide a group with no cancel-in-progress key at all. Reusable-only workflows, meaning those triggered solely by workflow_call, are exempt because their callers should define concurrency to avoid deadlocks and premature cancellations.