## Problem The self-hosted `spread-enabled` runner pool (3 runners: `runner-charmcraft-ps7-2-{1,2,3}`) frequently gets exhausted by stale, superseded workflow runs of **"Spread tests for source"** (`.github/workflows/spread.yaml`). Unlike `.github/workflows/spread-manual.yaml`, `spread.yaml` has **no `concurrency:` block**. This means every new push to a PR branch starts a brand-new spread run without cancelling the previous (now-superseded) run on the same branch/ref. Since there are only 3 self-hosted runners available for the whole repo, a couple of PRs that get pushed to frequently can occupy all 3 runners with runs whose results no longer matter, blocking every other PR's spread tests (including manual spread runs) from ever being scheduled. For example, at the time of writing, these two runs had been occupying all 3 runners for hours with newer commits already pushed on top of them: - https://github.com/canonical/charmcraft/actions/runs/36483384216 (`work/update-starbase-2026-09-24`) - https://github.com/canonical/charmcraft/actions/runs/36476203077 (`work/CHARMCRAFT-725-Implement-metadata-mediation-for-actions-config`) ## Proposal Add a `concurrency:` group to `spread.yaml`, scoped per-workflow-per-ref (so unrelated branches/PRs don't cancel each other), with `cancel-in-progress: true`, e.g.: ```yaml concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true ``` This mirrors the pattern already used in `spread-manual.yaml` (currently scoped even more broadly, to the whole workflow name — that one may be intentional given how few runners exist, but is worth double-checking too). ## Benefit Pushing new commits to a PR would automatically cancel the now-irrelevant in-progress spread run for that PR's previous commit, freeing up self-hosted runners for other PRs/branches instead of leaving them tied up running tests against stale code.