fix(automerge): never enqueue into a merge queue as GITHUB_TOKEN - #19
Merged
emkraan-deploy-bot[bot] merged 1 commit intoSep 23, 2026
Merged
Conversation
A merge queue attributes the merge_group event to whoever enqueued, and GitHub starts no workflow runs from GITHUB_TOKEN-caused events, so a GITHUB_TOKEN enqueue gets no merge_group CI and wedges at AWAITING_CHECKS. Verified across 18 PRs in 3 repos. Enqueue now requires the deploy-bot app and is skipped loudly otherwise; plain-repo merges keep their GITHUB_TOKEN retry.
emkraan-deploy-bot
Bot
deleted the
fix/automerge-never-enqueue-as-github-token
branch
September 23, 2026 16:11
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.
Summary
Removes the
GITHUB_TOKENfallback from merge-queue enqueue inreusable-automerge.yml. Enqueue now requires the deploy-bot app. If the app token is missing or the app is refused, the PR is skipped with a warning and retried by the next event or the sweep.Root cause of the "merge queue hard-wedge"
A merge queue attributes the
merge_groupevent to whoever enqueued the PR. GitHub starts no workflow runs from events caused byGITHUB_TOKEN, so an entry enqueued asgithub-actionsnever gets amerge_groupCI run, never sees its requiredcicheck, and sits atAWAITING_CHECKSuntil the timeout.Evidence, 18 PRs across 3 repos (enqueuing actor versus
merge_groupruns formed):merge_grouprunsgithub-actionsonlyemkraan-deploy-botThe HA integration repos looked healthy only because their
Validateworkflow also runs onpushwith no branch filter. The queue's push ofgh-readonly-queue/...is bygithub-merge-queue[bot](not suppressed), so that push run reportedcion the group commit. ha-shared-workflows' CI ispull_request+merge_grouponly, so nothing reportedciand it wedged. muninn #163/#164, documented on 2026-09-19 as a GitHub-side wedge, were the same cause.The wedged enqueues all came from runs acting as
github-actions: callers without app inputs, andworkflow_runevents, which runmain's caller (it lacked the app until today's rollout). All callers now pass the app. This PR makes sure a missing or failed app token can never silently reintroduce the wedge.Verification
emkraan-deploy-bot, itsmerge_groupCI run formed 18s later, and the queue merged it 51s after enqueue.