ci: serialise the automation workflows on the state they write

.github/workflows/architecture-submission.yml

@@ -14,6 +14,15 @@ permissions:
   pull-requests: write
   issues: write
 
+# Serialised per issue, matching the per-issue branch this workflow pushes:
+# removing and re-applying the label, or two maintainers applying it at once,
+# would otherwise have two runs writing the same
+# refs/heads/automation/architecture-issue-<n>. Keyed per issue rather than
+# repository-wide so two different submissions still proceed in parallel.
+concurrency:
+  group: automation/architecture-issue-${{ github.event.issue.number }}
+  cancel-in-progress: false
+
 env:
   NODE_VERSION: '22'
   SUBMISSION_LABEL: architecture-ready

.github/workflows/create-milestones.yml

@@ -13,6 +13,14 @@ permissions:
   issues: write
   pull-requests: write
 
+# Serialised repository-wide: the step snapshots every existing milestone
+# once, before the loop, so two concurrent dispatches both see a title as
+# absent and both try to create it. Not cancelled: a run stopped partway
+# through has already created milestones and assigned issues.
+concurrency:
+  group: create-milestones
+  cancel-in-progress: false
+
 jobs:
   create-milestones:
     runs-on: ubuntu-24.04

.github/workflows/import-architectures.yml

@@ -10,6 +10,13 @@ permissions:
   contents: write
   pull-requests: write
 
+# Serialised on the branch this workflow force-pushes; see the note in
+# refresh-radar-reports.yml. workflow_dispatch only, so two runs overlap as
+# soon as the button is pressed twice. Not cancelled, for the same reason.
+concurrency:
+  group: automation/import-architectures
+  cancel-in-progress: false
+
 env:
   NODE_VERSION: '22'
 

.github/workflows/pr-queue-hygiene.yml

@@ -8,6 +8,15 @@ on:
 permissions:
   contents: read
 
+# Serialised repository-wide: the job's state store is a hidden marker
+# comment it reads and then writes non-atomically, so two overlapping runs
+# (a dispatch during the 6-hourly cron) both find no marker and both post
+# one. Not cancelled: a run stopped after it has commented has still
+# written the state the next run reads.
+concurrency:
+  group: pr-queue-hygiene
+  cancel-in-progress: false
+
 jobs:
   hygiene:
     name: Flag stale conflicting PRs

.github/workflows/refresh-community-people.yml

@@ -9,6 +9,12 @@ permissions:
   contents: write
   pull-requests: write
 
+# Serialised on the branch this workflow force-pushes; see the note in
+# refresh-radar-reports.yml. Not cancelled, for the same reason.
+concurrency:
+  group: automation/refresh-community-people
+  cancel-in-progress: false
+
 env:
   NODE_VERSION: '22'
 

.github/workflows/refresh-radar-reports.yml

@@ -9,6 +9,17 @@ permissions:
   contents: write
   pull-requests: write
 
+# Serialised on the branch this workflow force-pushes. Two overlapping runs
+# (a dispatch during the nightly cron, or a cron that laps a slow run) both
+# write refs/heads/automation/refresh-radar-reports, and the loser's
+# --force-with-lease fails on stale info. Not cancelled: the run in flight
+# may already have pushed the branch, and `delete-branch: true` means a
+# half-finished run can delete the ref the other one's pull request is open
+# from.
+concurrency:
+  group: automation/refresh-radar-reports
+  cancel-in-progress: false
+
 env:
   NODE_VERSION: '22'