Skip to content

chore(ci): add concurrency control to all workflows#56

Open
avrabe wants to merge 3 commits intomainfrom
chore/ci-concurrency
Open

chore(ci): add concurrency control to all workflows#56
avrabe wants to merge 3 commits intomainfrom
chore/ci-concurrency

Conversation

@avrabe
Copy link
Copy Markdown
Contributor

@avrabe avrabe commented May 2, 2026

Summary

Adds a workflow-level `concurrency:` block to `.github/workflows/ci.yml`. Cancels superseded PR runs; never cancels runs on `main`, tags, or scheduled events. Org-wide pattern landing across 11 repos to clear the queue backlog.

Why

Org has 93 jobs perpetually queued; oldest is 23h old on `spar`. Without concurrency control, every `git push` to a PR branch starts a fresh run while previous runs on superseded commits keep executing. Concurrency control is the cheapest, lowest-risk fix and a strict prerequisite for any later runner migration.

Variant applied

File Variant Reason
`.github/workflows/ci.yml` default Filename not in compliance/release keyword list. The `sbom` and `provenance` jobs are gated `if: github.ref == 'refs/heads/main'` — the default pattern's conditional `cancel-in-progress: ${{ github.event_name == 'pull_request' }}` already protects them on main while still cancelling stale PR runs.

Diff

4-line addition. Strictly scoped to `.github/workflows/` per the brief.

```yaml
concurrency:
group: ${{ github.workflow }}-${{ github.head_ref || github.ref }}
cancel-in-progress: ${{ github.event_name == 'pull_request' }}
```

Verification

  • YAML parses
  • This PR's own CI run passes
  • Push a no-op follow-up commit; the earlier run shows Cancelled in the Actions UI within ~30s
  • After merge, post-merge `main` run completes normally (not cancelled)

Out of scope

Runner migration, job parallelisation, cache strategy, permissions hardening — tracked separately, depend on this PR landing first.

🤖 Generated with Claude Code

avrabe and others added 3 commits May 2, 2026 09:10
Why: org-wide CI is queue-bound — 93 jobs perpetually queued across
the org, oldest 23 hours old on spar, ~30-40% of compute spent on
runs against superseded commits. Adding workflow-level concurrency
cancels superseded PR runs (the cheapest, lowest-risk fix) and is a
prerequisite for the runner-migration work tracked separately.

What: a single workflow file in this repo, `.github/workflows/ci.yml`.
Default variant — group by workflow + head_ref (or ref on non-PR
events), cancel-in-progress only on `pull_request` events. The
sbom/provenance jobs in this workflow are gated on
`github.ref == 'refs/heads/main'`; the conditional cancel
(`${{ github.event_name == 'pull_request' }}`) leaves them untouched
on push-to-main while still cancelling stale PR runs.

Classification:
  - ci.yml → default variant (filename not in the
    release/compliance/sign keyword list; main-only attestation jobs
    are protected by the conditional cancel-in-progress).

Out of scope (per the brief): runner migration, job parallelisation,
cache strategy, permissions hardening — tracked separately, depend
on this PR landing first.

Verification:
  - YAML parses (python -c "import yaml; yaml.safe_load(...)").
  - Diff is 4 lines, only under .github/workflows/.
  - After merge, the next PR push will demonstrate cancel behaviour;
    main push will demonstrate non-cancellation.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…tion test)

Verifying the concurrency block from the parent commit by pushing two
no-op commits in quick succession; the second should cancel this run.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…test)

The previous push's run should be cancelled by this one if the
concurrency block is wired correctly.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant