DevOps / GitHub Actions Interview Questions
How do you use concurrency groups to cancel outdated workflow runs in GitHub Actions?
The concurrency: key limits how many workflow runs (or jobs) with the same group name can be active simultaneously. Setting cancel-in-progress: true automatically cancels any run in the same group that is already in progress when a new one starts — perfect for preventing stacked deploys or redundant CI runs on fast-pushed branches.
# Cancel any previous CI run on the same branch when a new commit is pushed concurrency: group: ci-${{ github.ref }} cancel-in-progress: true jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: npm test
The group: string is the identifier. Runs sharing the same group string compete for the single-active-run slot. Using ${{ github.ref }} scopes the group to a branch, so pushes to main only cancel each other, not pushes to feature branches.
For deployment workflows you often want a different policy: queue new runs rather than cancel them, and never cancel a run that is already deploying. Achieve this by omitting cancel-in-progress (defaults to false):
concurrency: group: deploy-${{ github.ref }} # cancel-in-progress defaults to false â runs are queued, not cancelled
Concurrency can also be set at the job level (not just workflow level) to limit parallelism for a specific job such as a deployment job while leaving other jobs unaffected.
jobs: deploy: concurrency: group: deploy-production cancel-in-progress: false
More Related questions...