Repository navigation
fix(ci): never cancel a pull request's Queue check - #539
Conversation
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 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. WalkthroughThe queue workflow removes its concurrency group and Merge Risk:
|
Problem
moq-dev/rust2#536 made the required
Queuejob report the reusable build's result:needs: buildwithif: always() && github.event_name == 'merge_group'. On a pull request that job now waits forbuildto skip before it skips itself. The workflow-levelconcurrencygroup (cancel-in-progress: true) cancels a PR's run when a second event for the same PR arrives within seconds, such assynchronizefrom a push followed byeditedfrom a body edit. The cancelled run'sQueuecheck then reports cancelled, which fails the required check and blocks enqueueing.Seen on moq-dev/quest#445, head
adb28aa6: run 41683755363 hadQueuecancelled whileQueue buildandReport Queueskipped, next to run 41683758122, which skipped normally. Both were created in the same second.Approach
Drop the workflow's
concurrencygroup and say why in a comment:Queuecheck always ends skipped.Queuestill runs underalways()and fails when the build fails or is cancelled, so a skipped context can't pass the group.Alternatives
cancel-in-progress: ${{ github.event_name != 'pull_request' }}: rejected. A group without cancel-in-progress still cancels a pending run when a newer one queues (GitHub docs on concurrency), so three quick events would still cancel the middle run'sQueue.Queueskip immediately off merge groups: not possible while it keepsneeds: build, since a job waits for its needs before it evaluatesif.always()is what keeps it running when the build is cancelled (status check functions). Droppingneedswould lose the build's result.Impact
Related
Review
quest review --base origin/main), gpt-6.1-sol, medium efforte6356c694ab5c0b91a46d1573653c3cfe5fe3344Follow-ups
(Written by Claude Opus 5.5)
🤖 Generated with Claude Code