From ae431e3ff749861b244f6be9b2211c66012d3e95 Mon Sep 17 00:00:00 2001 From: Christopher Bischoff Date: Fri, 24 Jul 2026 21:54:54 +0200 Subject: [PATCH] ci: serialize Build runs per ref MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Merging #5 and #6 twenty-eight seconds apart put two Build runs on main at once, and the older one's release step failed with HTTP 403 on POST /releases while the newer one created v1.0.10 without trouble. The 403 was never explained — the job holds contents:write, the protect-main ruleset targets branches rather than tags, and the same configuration succeeded moments later — but two release jobs racing to create refs in one repository is not a state worth keeping either way. The concurrency group queues runs per ref. On main nothing is cancelled, so every merge still produces its release; on pull requests superseded runs are cancelled as before, since a stale PR build has nothing to publish. The known trade-off: three merges in quick succession would leave the middle run queued, and GitHub drops a queued run when a newer one arrives — that commit would get no release. For a repository that merges a few times a month that is a better failure mode than a race. Co-Authored-By: Claude Opus 5 (1M context) --- .github/workflows/build.yml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index 5bec8bf..1fcad19 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -6,6 +6,10 @@ on: pull_request: workflow_dispatch: +concurrency: + group: ${{ github.workflow }}-${{ github.ref }} + cancel-in-progress: ${{ github.event_name == 'pull_request' }} + permissions: {} jobs: