docs(ci): document merge-queue GH006 race and stuck-promotion diagnosis - #1106
Open
mrbobbytables wants to merge 1 commit into
Open
Conversation
Investigated projectbluefin#929 (stable promotion stuck since July 20). The current Execute Release/Promote failures trace to E2E gate regressions already owned upstream (testsuite smoke-a AT-SPI/Dash-to-Dock, common's toggle-updates TTY fix already merged and picked up on testing via Renovate). No bluefin-side code lever exists for those. Along the way, found a previously undocumented, currently-happening pattern worth capturing so future triage doesn't re-diagnose it: the promote-testing-to-main workflow can log a spurious GH006 'protected branch' failure when a run's force-push races another run's already- enqueued PR. It's benign (concurrency group already serialized the real state change), but distinguishing it from a genuine promotion block requires checking the promotion PR's timeline. Also documents that a promotion PR cycling through added/removed-from-merge-queue for multiple days running means the release gate genuinely fails on the squashed content — i.e. the real, currently-active blocker for projectbluefin#929. Assisted-by: Claude Sonnet 5 via GitHub Copilot Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
hanthor
approved these changes
Aug 16, 2026
hanthor
left a comment
hanthor
left a comment
Member
There was a problem hiding this comment.
Docs-only addition to failure-modes.md, single file, no workflow/behavior changes. The described GH006 race (force-push landing while another run is already enqueuing) is a plausible and correctly-diagnosed benign race given the concurrency group serializes runs, and the distinction drawn between that noise and a genuinely-cycling added_to_merge_queue/removed_from_merge_queue pattern (pointing at real release-gate failures) is a useful, accurate triage aid. Nothing here contradicts current workflow behavior as far as I can tell from the referenced files.
Generated by Claude Code
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
Investigating #929 ("ci: stable promotion has not completed since July 20"). Re-ran the current triage against the latest Execute Release run and the
auto/promote-testing-to-mainpromotion PR to confirm what still blocks stable and to check whether anything changed since the last two triage comments on the issue.Confirmed still blocking, no bluefin-side lever (owned upstream):
bluefinsmoke-a:Dash to Dock panel is visible/ Firefox AT-SPI checks still fail (GDBus UnknownMethod error, object does not exist at path /org/gnome/Shell/Extensions; Firefox address bar not found). This is the same testsuite-side regression flagged in the 2026-08-10 comment; still no tracking issue in projectbluefin/testsuite as of this run.bluefin+bluefin-nvidiacommon-b:ujust toggle-updatesfailed on the 2026-08-10 run with 'unable to pick selection: could not open a new TTY'. Traced this to feat(ujust): honor ACTION in toggle-updates for non-interactive use common#966 (merged 2026-08-09), which fixes exactly this by honoring an explicit ACTION argument.testing's image-versions.yml already picked up the fixed digest via Renovate (ghcr.io/projectbluefin/common@sha256:6d35613..., PR chore(deps): update ghcr.io/projectbluefin/common:latest docker digest to 6d35613 #1105) - this repo has nothing further to change here.New finding, not previously documented: the promote-testing-to-main to merge-queue path itself has a benign-but-confusing failure mode. A promotion run can fail with 'GH006: Protected branch update failed ... added to a merge queue' when its force-push races another run that already enqueued the PR (confirmed via the promotion PR's timeline - interleaved head_ref_force_pushed/added_to_merge_queue events within the same minute). Distinct from that, the promotion PR itself has been cycling added_to_merge_queue -> removed_from_merge_queue roughly every two hours, day after day, which means the release-gate check is genuinely failing on the squashed testing content - i.e. it's gated on the same E2E regressions above, not a promotion-workflow bug.
Change
Documentation-only: adds a section to docs/skills/ci/references/failure-modes.md describing this GH006 race and how to tell it apart from a genuinely stuck promotion, per AGENTS.md's 'update the matching skill when a session surfaces a non-obvious pattern.' No workflow, build, or image behavior changes.
Validation
Related: #929, projectbluefin/common#966, projectbluefin/common#951.