🏗️🔧:make the queue say why it could not start - #896
Conversation
Every step that reports back to a pull request is gated on the app token, because reporting takes one. So a token that never minted reports nothing at all: a bare red check, no comment, and the label still sitting there as though the queue had yet to look. That is the first failure a queue nobody has run before will produce, and the two things that cause it -- an app not installed on the repository, and a private key that lost its BEGIN and END lines on the way into a secret -- are indistinguishable from the outside. A workflow annotation needs no token and no permission, so it is the one report that survives having no credentials at all. It names both causes and says the label has to come off by hand, since `unlabeled` is not a trigger and reapplying it would otherwise start nothing. The note above the two reporting steps also claimed they need only the app's pull request permission. They do not: labels and comments are issue endpoints even when the number belongs to a pull request, so they need `Issues: write`. Left uncorrected that is an hour spent wondering why a queue that merges cannot comment. Signed-off-by: Derek Lewis <DerekNonGeneric@inf.is> Assisted-by: Claude-Code:claude-opus-5
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughThe commit queue workflow now documents ChangesCommit queue workflow
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to The workflow now explains token-minting failures without credentials and documents the required Issues permission. No current merge-blocking risk remains. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
The commit queue is silent in exactly the failure it is most likely to
produce first.
The gap
Both steps that report back to a pull request are gated on the app
token:
They have to be — reporting takes a token. But that means a token that
never minted produces a bare red
Landcheck, no comment, and thelabel still sitting on the pull request as though the queue had yet to
look at it.
That is the first thing a queue nobody has run before will do if
anything is wrong with its credentials, and the two causes — the app
not installed on the repository, and a private key that lost its
BEGIN/ENDlines on the way into a secret — are indistinguishablefrom outside. Both are live unknowns here: I can confirm the secrets
reach the repo, but not that the app is installed, which needs
admin:org.The fix
A workflow annotation needs no token and no permission, so it is the
one report that survives having no credentials at all. It names both
causes and says the label has to be taken off by hand —
unlabeledisnot a trigger, so reapplying it would otherwise start nothing.
No permissions change. The job keeps
contents: read; wideningGITHUB_TOKENtoissues: writejust to post a failure comment is alarger surface than this warrants on a
pull_request_targetworkflow.Also: a comment that was wrong
The note above those steps claimed they "need only the pull request
permission the app already has". They do not — labels and comments are
issue endpoints even when the number belongs to a pull request, so
they need the app's
Issues: write. Per GitHub's permissionsreference. Left uncorrected it is an hour spent wondering why a
queue that can merge cannot comment.
Summary by CodeRabbit
Documentation
Bug Fixes