6 ms·
Yes. But look at the bottom. There's an image with the PR review screen. There's one change: * Normally, the big green button says "Merge pull request" * Now,
by tottenhm 3y ago
Yes. But look at the bottom. There's an image with the PR review screen. There's one change:
* Normally, the big green button says "Merge pull request"
* Now, the big green button says "Merge when ready"
In a large project with lots of activity, a stampede of people pressing "Merge" at the same time will cause trouble. "Merge when ready" is supposed to solve this.
It seems to mean:
> "GH, please merge this, but take it slow. Re-run the tests a few extra times to be sure."
- phailhaus 3y agoHere's in-depth details on how it works. [1] Basically, each PR gets put in its own branch with the main branch + all the PRs ahead of it merged in. After tests pass, they are merged in order. [1] https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue https://docs.github.com/en/repositories/configuring-branches...
- plonk 3y agoSo does each new PR start new tests that will supersede the previous PR’s tests? If one PR’s tests fail, does it block all PRs behind it in the queue? I’ve read docs several times and never found them very clear about the details.
- striking 3y agoEach PR on the queue is tested with whatever commits it would have were it merged to the target branch in queue order. So if the target branch already has commit A and commits B and C are in queue, commit D will be tested on its own temporary branch with commits A B C and D. If the tests for C fail, C is removed from the queue, and D is retested with just commits A B and D (because that's what would be on the target branch by the time it merges).
- plonk 3y agoOK, thank you.
- dijksterhuis 3y agoAha, so GitHub merge queue = GitLab merge trains (or at least very similar).
- masklinn 3y agoYes that’s pretty much what it is. Both are replicas of bors, and implementations https://graydon.livejournal.com/186550.html https://graydon.livejournal.com/186550.html
- actionfromafar 3y agoAlso continuous integration best practices advance one funeral at a time, it seems.
- hashar 3y agoBors is also very similar to the Zuul CI system used for OpenStack. It has the equivalent of a merge queue (with additional support for cross repositories dependencies): https://zuul-ci.org/docs/zuul/latest/gating.html https://zuul-ci.org/docs/zuul/latest/gating.html You can then have pull requests from different repositories all serialized in the same queue ensuring you don't break tests from any of the repositories participating.