Repository navigation
gh-prs-merge: stop skipping ready PRs, and stop the sweep queueing behind one - #100
Merged
Merged
Conversation
…hind one Three separate ways a sweep of ready PRs came back with nothing merged. UNSTABLE was treated as a blocker. It means mergeable with a non-required context that is not green — GitHub takes the merge, and the check rule is the stricter test anyway, so demanding CLEAN only skipped PRs that were ready. tronbrowser.dev#124 sat unmerged with two green checks and nothing wrong with it. CLEAN, HAS_HOOKS and UNSTABLE now pass, and UNSTABLE only when there were checks to corroborate it. Checks are judged before the aggregate state, so a red check names itself instead of hiding behind mergeStateStatus=UNSTABLE. A settled conflict cost a round trip and two lines. update-branch merges the base into the head, which cannot work over a conflict, and DIRTY is GitHub having already decided there is one. It was asked anyway, told no, and the refusal printed as FIXME and then again as SKIP. Now it is not asked, and the PR is reported once. The wait held up the whole sweep. One unfinished test suite stood in front of every PR behind it for up to --fix-wait, each. PRs whose checks are still running are parked and judged in a second pass, so the ready ones merge now; --fix-wait is the budget for that queue as a whole rather than per PR. Verified against the live orgs: the sweep that skipped everything now merges tronbrowser.dev#124 and crawlproof.com#291, and reports nightcell7#90's conflict once. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ThreatCrush Security Scan23 finding(s) HIGH/CRITICAL: 4 | MEDIUM: 10 | LOW: 9
Snippets are redacted; ThreatCrush never prints matched credential material. |
ralyodio
added a commit
that referenced
this pull request
Sep 24, 2026
…et it in (#101) `node_modules/` with a trailing slash matches directories only. A *symlink* named node_modules is not a directory, so the rule never applied to it, and a `git add -A` committed one in #100. Pulling that landed a symlink pointing at the checkout's own node_modules over the real directory — a self-referential loop, and every command in the repo that resolves a dependency fails with ELOOP until the symlink is deleted and the install repeated. Drop the trailing slash so the rule matches the symlink too, and untrack the file. Verified: `git check-ignore` now claims a node_modules symlink, and one sitting in the working tree no longer shows up in `git status`. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
A sweep of ready PRs came back with nothing merged. Three separate causes.
UNSTABLEwas treated as a blockerIt means mergeable, with a non-required context that is not green. GitHub takes the merge, and the "every check is pass or skipping" rule is the stricter test anyway — so demanding
CLEANonly ever skipped PRs that were ready.tronbrowser.dev#124sat unmerged with two green checks and nothing wrong with it.CLEAN,HAS_HOOKSandUNSTABLEnow pass, andUNSTABLEonly when there were checks to corroborate it. Checks are also judged before the aggregate state, so a red check names itself instead of hiding behindmergeStateStatus=UNSTABLE.A settled conflict cost a round trip and two lines
update-branchmerges the base into the head, which cannot work over a conflict, andDIRTYis GitHub having already decided there is one. It was asked anyway, toldCannot update PR branch due to conflicts, and the refusal printed asFIXMEand then again asSKIPdirectly underneath. Now it is not asked, and the PR is reported once.The wait held up the whole sweep
One unfinished test suite stood in front of every PR behind it, for up to
--fix-waiteach. PRs whose checks are still running are parked and judged in a second pass, so the ready ones merge immediately;--fix-waitis now the budget for that queue as a whole.Verification
Live, against the same orgs as the failing run:
test/prs-merge.test.ts38 passing, typecheck clean. Six failures intest/root-ubuntu.test.tsare pre-existing — baselined at20e6663with the identical count and unrelated to this change.🤖 Generated with Claude Code