Add merge queue CI optimisation
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 38/100
Research direction
No files or tests are named. Start by locating the merge-queue implementation and the existing “Only merge non-failing pull requests” option, then trace how stacked PRs are evaluated. Done means a queued stack can run CI only on its last PR and merge atomically, while a partial queue still merges when its last queued PR succeeds.
Written by the indexing model from the issue text.
Description
The problem
We use stacks a lot, and often mid stack PRs have some CI failures that are fixed above.
When I merge a stack of 5 PRs, I don't need to run CI in each of them, it's OK to skip 1-4 and only run CI in 5th. It saves A LOT of wasted runner minutes.
Current state
You have this checkbox "Only merge non-failing pull requests":
Imagine we have added 5 stacked PRs to a merge queue, with CI like this
PR 1 pass ✅
PR 2 pass ✅
PR 3 fail ❌
PR 4 pass ✅
PR 5 fail ❌
Checkbox set:
It will run CI on 5 pull requests, merge 1-2
Checkbox not set:
It will run CI on 5 pull requests, merge 1-4
Proposal
It is greedy to merge something now. I want it to merge a queued atomic stack instead.
In order to make it work, you need another checkbox "merge a queued stack atomically and only run CI on the last PR", where it will only run CI on PR 5, and it will not merge 1-2 or 1-4 of I queued 1-5.
However, if I only added 1-2 or 1-4 to the merge queue - it will merge, because the last queued PR succeeded.
For context: it is not rare for us to hit a 50 PRs limit in a graphite, and 20 PRs stacks are very usual. Saving 20x runner minutes is a huge deal.
- Dominant language
- Go
- Stars
- 1.5k
- Forks
- 73
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 7
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from github/gh-stack
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
feature request topic: cli - general
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
feature request topic: auto-merge
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
bug topic: docs
Difficulty 1/5 Under an hour Newbie friendliness 68/100
Similar issues
-
textual definition
Difficulty 1/5 Under an hour Newbie friendliness 90/100
geneontology/go-ontology#32653 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 75/100
-
needs design
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Priority/High ready-for-agent Severity/Major Type/Bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100