From 269f4119e5f43ae9b363b9436d69e3c3e35efcc5 Mon Sep 17 00:00:00 2001 From: mervin008 Date: Sun, 27 Sep 2026 16:04:05 +0200 Subject: [PATCH] Run one sync at a time certpilot#118 and certpilot-agent#6 merged three seconds apart on 2026-09-27. Each dispatched a sync, and both runs checked out the same main. The first pushed. The second was rejected as not a fast-forward and failed. Nothing was lost that time: both runs would have published the same two pages. A rerun could not recover it anyway, because a rerun checks out the original commit again and is rejected the same way. The failure reads as a broken pipeline all the same, and it recurs on any burst of merges, such as the five phase-2 pull requests queued on certpilot. A workflow-level concurrency group queues runs rather than cancelling them, because a run in progress may be halfway through publishing. GitHub keeps one pending run per group, so a burst ends with a run for the newest dispatch, which reads what the earlier ones would have. Co-Authored-By: Claude Opus 5.5 --- .github/workflows/sync.yml | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/.github/workflows/sync.yml b/.github/workflows/sync.yml index e99c270..350b4fc 100644 --- a/.github/workflows/sync.yml +++ b/.github/workflows/sync.yml @@ -18,6 +18,16 @@ on: - cron: '0 6 * * 1' workflow_dispatch: +# One sync at a time. Two repositories merging within a minute of each other +# dispatch two runs, both check out the same main, and the second push is +# rejected as not a fast-forward: certpilot#118 and certpilot-agent#6 did +# exactly that on 2026-09-27. Queued rather than cancelled, because a run in +# progress is publishing something. GitHub keeps one pending run per group, +# so a burst of merges ends with the newest, which reads both repositories. +concurrency: + group: sync + cancel-in-progress: false + permissions: contents: write pull-requests: write