In GitHub Actions, what does a concurrency group with cancel-in-progress do?

## The problem it solves Push three commits to a pull request in five minutes and, by default, GitHub Actions starts three full runs. The first two are already obsolete — nobody will look at their results — but they hold runner capacity and burn minutes. On the other side of the pipeline, two deploy runs racing to the same environment is worse than wasteful: it is a correctness problem. `concurrency` is the one key that addresses both. ## Syntax ``` concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true ``` `group` is any string; the expressions are just how you make it meaningful. Two runs are in the same group if their evaluated group strings are equal, compared **case-insensitively**. The shorthand `concurrency: my-group` sets the group with `cancel-in-progress` defaulting to false. ## The three-run rule The queueing behaviour is small but exact, and it is what interviewers probe. - **`cancel-in-progress: true`.** A new run cancels any in-progress run in the same group and starts. Cancellation propagates to the running jobs, which receive a cancellation signal; `if: always()` steps still get their chance to run, `if: cancelled()` steps run specifically on this path. - **`cancel-in-progress: false`** (the default). The new run enters `pending` and waits for the in-progress run to complete. - **A third arrival, either way.** Only one run may be pending per group. When a newer run arrives, the currently pending run is **cancelled** and the newcomer takes its place. So the steady state is at most one running plus one queued — the oldest in flight and the newest waiting, with everything in between discarded. ## Choosing the group key The group expression *is* the design decision. - `${{ github.workflow }}-${{ github.ref }}` — per workflow, per branch or PR. The default choice for build/test workflows: superseded commits on one branch cancel each other, unrelated branches never interfere. - `${{ github.workflow }}` alone — every branch shares one group. Almost always a bug: a push to a feature branch cancels the run for `main`. - `deploy-production` (a constant) — one global lane, typically with `cancel-in-progress: false`, so deploys queue rather than race. - `${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}` — a common variant keeping pull-request runs distinct from branch runs of the same ref. Note that `github.ref` differs by event: on a `pull_request` event it is `refs/pull/<n>/merge`, on a push it is `refs/heads/<branch>`. That is usually what you want — the PR run and the branch run stay in separate groups — but it explains why two runs you expected to collide sometimes do not. ## Workflow level versus job level Declared at the top level, `concurrency` governs the whole run. Declared inside a job, it governs that job only, and other jobs in the same run proceed independently. The idiomatic combination is an aggressive workflow-level group for the fast feedback path plus a conservative, non-cancelling job-level group on the deploy job: ``` concurrency: group: ci-${{ github.ref }} cancel-in-progress: ${{ github.event_name == 'pull_request' }} jobs: deploy: concurrency: group: deploy-production cancel-in-progress: false ``` `cancel-in-progress` accepting an expression is what makes that first block safe: pull-request runs are disposable and get cancelled, while runs on the default branch are never interrupted mid-deploy. ## Failure modes to name **Cancelling a deploy halfway.** Terraform mid-apply, a database migration mid-transaction, a partially-rolled-out service. Deploy jobs want a constant group and `cancel-in-progress: false`; if the work is genuinely not resumable, queueing is the only safe answer. **Too-broad a group.** Constant groups on a build workflow serialise the whole repository and make CI feel mysteriously slow — runs sit `pending` with no explanation on the run page beyond "waiting". **Expecting deduplication.** Concurrency does not merge runs or skip identical work; it cancels and queues. It also does not span repositories — groups are scoped to the repository. **Confusing it with a matrix limit.** `max-parallel` bounds parallel legs inside one job's matrix; `concurrency` bounds runs or jobs across the repository. Different keys, different scope. ## Why interviewers like it It is a two-line change with visible cost impact — often the single biggest reduction in wasted runner minutes available in a repository — and it has a genuine sharp edge, since the same two lines applied to a deploy workflow can interrupt production work. A candidate who can state the queueing rule *and* the deploy caveat has clearly run this in anger.