Q: How do you implement workflow concurrency in GitHub Actions, and when should you cancel in-progress runs?

Save CI runner minutes and reduce queue congestion during rapid pull request iterations:

# Branch-level CI concurrency configuration
name: CI Pipeline
on:
  pull_request:
    branches: [main]

concurrency:
  group: ci-${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

• Dynamic Concurrency Group: Combine the workflow name and git branch reference (github.workflow and github.ref) to scope concurrency per PR.
• Cancel In-Progress: Setting cancel-in-progress: true automatically aborts the currently running job as soon as a new push occurs on the same branch.
• Cost Optimization: Eliminates runner waste by not testing obsolete commits that have already been superseded.

Prevent simultaneous deployments from conflicting over state locks, database migrations, or cloud resources:

# Environment-level deployment concurrency (Mutual Exclusion)
name: Deploy to Production
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    concurrency:
      group: deploy-production-api
      cancel-in-progress: false
    steps:
      - uses: actions/checkout@v4
      - name: Deploy application
        run: ./deploy.sh production

• Static Environment Group: Group deployments by target environment name (e.g. deploy-production-api).
• Queue Without Aborting: Set cancel-in-progress: false so that if two merges happen back-to-back, the second deployment waits in queue until the first completes successfully.
• Job-Level Concurrency: Apply concurrency at the individual job level rather than the entire workflow if only the deploy phase requires mutual exclusion.