Speed up release preparation by listing merged pull requests - #9855
Open
hsbt wants to merge 6 commits into
Open
Conversation
Mapping each commit since the previous release back to a pull request took 102 `gh search prs` calls with a forced sleep every 28 of them, plus one REST fetch per pull request found, about 570 requests and eight to ten minutes for a minor release. `mergeCommit.oid` names the commit a pull request leaves on its base branch under every merge strategy, so one listing call intersected with the local history answers the same question exactly, and without depending on the commit search index. For 4.1.0.beta1 both find the same 466 pull requests, the listing in six seconds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
hsbt
force-pushed
the
release-tool-fast-pr-discovery
branch
from
September 4, 2026 06:56
b3540e5 to
d4affe2
Compare
hsbt
changed the title
GitHub reports `mergeCommit` as null for a merged pull request whose merge commit no longer exists, and 190 of the 876 pull requests this repository merged before 2019 are in that state. Reading `["oid"]` off it raised a bare NoMethodError in the middle of a release. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The reachability test stubbed every backticked command with one canned SHA, so it passed no matter what range `pull_requests_merged_into` asked git for, a reversed one included. It now builds a two commit repository and asserts that only the pull request whose merge commit is inside the range survives. CI checks out with no history, so the range cannot come from this repository. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Only the `gh pr list` call checked its exit status. A range git cannot resolve left an empty reachable set that filtered out every pull request, and since nothing raises for a minor release, one would have cut a changelog section with no entries. A tag git cannot resolve surfaced as `invalid xmlschema format: ""` from the date arithmetic instead of naming the ref. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`relevant_pull_requests`, the only caller, already sorts by merge date. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The reason a truncated listing is refused was stated on the constant and again above the method that refuses it, and two comments restated their own method signature. The header also claimed the new lookup does not ask the search index, which is wrong: `gh pr list --search` is the same backend as the commit search it replaces, so it inherits the same indexing lag. Co-Authored-By: Claude Opus 5 <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.
Preparing a release now takes seconds instead of minutes.
Mapping commits back to pull requests used about 570 requests: 102
gh search prscalls with a forced sleep every 28, then one REST fetch per pull request found.mergeCommit.oidnames the commit a pull request leaves on its base branch under every merge strategy, so onegh pr listcall intersected with the local history answers the same question exactly.For 4.1.0.beta1 the old scan and the new listing find the same set of pull requests, and the listing takes six seconds instead of eight to ten minutes. A full
DRYRUN=1 rake prepare_release[4.1.0.beta1]now finishes in 39 seconds and produces the same changelog section.This also drops the workaround for force-pushed commits that
gh search prscould still associate with a pull request, since reachability answers that directly.One narrowing worth naming: the listing asks for
--base master, so a pull request that targeted an intermediate branch which was later merged into master no longer shows up, where the commit scan found it through its commits. Nothing in the last nine months hits that, and this repository merges into master directly.Generated with Claude Code