🏗️✨：land a pull request when it is labelled - #1815
Merged
Merged
Conversation
The commit queue. Applying `commit-queue` to a pull request hands it to the same task that has been landing them by hand, running as a GitHub app rather than as anyone in particular. Two things are checked before anything merges, beyond what landing by hand already checked. Every check has to have finished and passed, since a label applied while one was in flight says nothing about how it turned out. And whoever applied the label has to have the right to push: labelling needs only triage, so without this the label would quietly hand out an access level GitHub had withheld. Nothing here checks out or runs the branch's code. `pull_request_target` reaches secrets, which is why it is used, and that is only safe while the code being read belongs to the base branch. Signed-off-by: Derek Lewis <DerekNonGeneric@inf.is> Assisted-by: Claude-Code:claude-opus-5
✅ Deploy Preview for gh-pages-openinf ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
DerekNonGeneric
added a commit
that referenced
this pull request
Aug 15, 2026
🏗️🔧：survive a failed call to the GitHub API Landing #1815 crashed once with a stack trace and worked on a second run, unchanged, which is what a transient 502 or a throttled request looks like from here. Reads are now tried twice; a merge is not, since repeating one that already reached GitHub would report the pull request as unmergeable when it had in fact just merged. Anything still unexpected reports a line rather than a stack trace. That needed the repository, the default branch and the actor to be worked out when first wanted instead of as the file loads, since nothing could catch them failing up there. 🏗️🔧：stop the queue waiting for itself The queue reports as a check like any other job, so requiring every check to have finished meant requiring itself to have finished, which it cannot do until it stops waiting. Labelling #1816 deadlocked on exactly that, which is what an end-to-end test is for. Its own run is identified by the run id in the check's details URL rather than by the job's name, so renaming the job cannot quietly reintroduce the deadlock. Every other run still counts, including another queue run on the same commit. Signed-off-by: Derek Lewis <DerekNonGeneric@inf.is> Assisted-by: Claude-Code:claude-opus-5 PR-URL: #1816
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
1 participant
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.
Phase 3. Applying
commit-queueto a pull request hands it to the same task that has been landing them by hand, running as the app rather than as anyone in particular.The four decisions, as built
GITHUB_REPOSITORYin a workflow, the git remote in a terminal, and the default branch asked of the API. A vendored copy needs one import line changed and nothing else.actions/create-github-app-tokenmints a token per run fromLAND_APP_IDandLAND_APP_PRIVATE_KEY.build/shared/landing.mtsand the task — and neither knows where it is.The two new guards
Every check must have finished and passed. Anything still running counts against it: a label applied while a check was in flight says nothing about how that check turned out. Neutral and skipped do not count against it, since neither is a complaint. Both kinds are read — several services on this repository report the older commit statuses rather than check runs, and looking only at check runs would call a red commit green.
Whoever applied the label must have the right to push. On GitHub, triage permission can apply labels but cannot push, so without this the label would quietly hand out an access level GitHub had withheld. Run from a terminal instead of a workflow, the check falls back to whoever owns the token, so there is no path where it is silently skipped.
Seven tests on the verdict logic, which is pure and lives in
landing.mts; only the fetching is in the task.On
pull_request_targetIt is used because
pull_requestgives a fork a read-only token and no secrets, and #1274 came from a fork. It is only safe because nothing here checks out or executes the branch's code: the checkout is the base branch, and the branch under review is fetched solely so its commit messages can be read. The workflow says so at the top, and says not to add a build, install or test step — those belong in the checks it waits for, which run without a token that can write anything.Verification
nps test— 16/16 tasks, 63/63 testscommit-queuelabel now existsImportant
This one has to land the old way.
pull_request_targettakes the workflow from the base branch, so a workflow added by a pull request cannot run on that same pull request. Once it is onlive, the next pull request is the first real test — and the thing to watch is whether the merge triggersdeploy.yml, since a merge that does not is the whole reason we are not usingGITHUB_TOKEN.