From e6356c694ab5c0b91a46d1573653c3cfe5fe3344 Mon Sep 17 00:00:00 2001 From: Luke Curley Date: Tue, 3 Nov 2026 09:33:47 -0800 Subject: [PATCH] fix(ci): never cancel a pull request's Queue check The workflow-level concurrency group cancelled a pull request's run when a second event for the PR arrived within seconds (a push, then a body edit). Its `Queue` job, which waits on `build` before it skips, then reported cancelled and failed the required check. Even without cancel-in-progress, a group cancels a pending run, so drop the group: merge groups each have their own ref, and a repeated dispatch only reports the same skipped context. Co-Authored-By: Claude Opus 5.5 --- .github/workflows/queue.yml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/.github/workflows/queue.yml b/.github/workflows/queue.yml index 6fb6b53fb..840e9c8c7 100644 --- a/.github/workflows/queue.yml +++ b/.github/workflows/queue.yml @@ -31,12 +31,12 @@ on: permissions: contents: read -# Each group has its own ref, so a group never cancels another; a pull request's -# skipped runs replace their own. Dispatches all run on main, so each PR head's -# report has its own group too. -concurrency: - group: queue-${{ github.ref }}-${{ inputs.sha }} - cancel-in-progress: true +# No concurrency group. A pull request's `Queue` job waits on `build` before it +# skips, so cancelling the run then, as a second event for the PR would, +# reports `Queue` cancelled and fails the requirement; even a group without +# cancel-in-progress cancels a pending run. Each merge group has its own ref, so +# its run never had another to replace, and a repeated dispatch only reports the +# same skipped context twice. jobs: # The build runs in queue-build.yml so its runner group can admit that