ci: run one workflow per pull request with concurrency groups - #722

What

Adds a top-level concurrency block to check.yml, lint.yml and features.yml:

concurrency:
  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

check.yml also gains name: Check. Without a name: key its github.workflow evaluates to the literal string .github/workflows/check.yml, which is both the run name the Actions UI shows and, now, part of the concurrency group key. lint.yml and features.yml already carry names.

release.yml is deliberately left alone — it runs on tags, not on the PR/push triggers this addresses.

Why

All three workflows fire on the same triggers: pull_request plus push to main (check.yml adds workflow_dispatch). In a stacked-PR chain, one git push that updates several branches makes GitHub fire a pull_request synchronize both for the PR whose head moved and for the PR whose base moved. The result is two runs of the same workflow, for the same PR, on the same commit.

Every run currently on PR #716's head SHA b9a4f00a, straight from the API:

Six runs where three would do — every workflow duplicated, one second apart, all pull_request events on an identical commit. PR #717 shows the same pattern: runs 36569872967 (12:42:06Z) and 36569873206 (12:42:07Z), both on head ec5d1b19.

Each duplicated check run costs a full 7-version matrix (~16-19 minutes), plus the duplicated lint and build.

Design notes

• github.workflow belongs in the group key. Without it the three workflows share one group and cancel each other. Lint finishes in ~22 seconds and would kill the 19-minute check run.
• Keying on github.event.pull_request.number — the PR, not the branch — is what actually de-duplicates, because the duplicate events are two synchronizes for the same PR.
• The || github.ref fallback is required. pull_request.number is empty for push: main and for workflow_dispatch; without a fallback every non-PR run collapses into one group named <workflow>-, and consecutive pushes to main would cancel each other. With it, main gets refs/heads/main and a workflow_dispatch on a branch gets refs/heads/<branch> — a different group from that branch's PR group, so a manual re-run cannot be cancelled by a PR event.
• cancel-in-progress is gated on github.event_name == 'pull_request' on purpose. On push: main every merge commit should get a run that completes; cancelling would leave commits on main with no finished check and degrade required-status-check history.
• Not keyed on the head SHA. That would stop a newer push from superseding an older run, which is the main benefit being bought here.

Tradeoff

When merging down a stack one PR at a time with minutes between merges, a base-branch update can cancel a run that is already 15 minutes into the 19-minute suite and restart it from zero. Total CI minutes still drop, but time-to-green for that one PR can get worse.

cancel-in-progress: false is the alternative: it collapses the duplicate by queueing instead of replacing, which saves concurrency slots but not minutes. The cancelling variant is the right default — a superseded run is testing a commit nobody is waiting on.

Note for tooling

Superseded runs conclude cancelled, not success. The PR status rollup is unaffected, since GitHub uses the latest run per check name, but any tooling that asserts "every run on this SHA succeeded" needs to treat cancelled as skippable.

Validation

• All three files parse: yaml.safe_load succeeds on each. (on: parsing as the boolean key True under YAML 1.1 is expected.)
• concurrency is top-level (column 0) in exactly the three files, not nested under jobs:.
• ruff check . passes.
• Diff touches exactly check.yml, lint.yml and features.yml.

🤖 Generated with Claude Code