3 ms·

Say two PRs get sent in by two different developers. CI builds both, passes them. Reviewer comes and approves PR#1, it is merged into master. Depending how muc

Say two PRs get sent in by two different developers. CI builds both, passes them. Reviewer comes and approves PR#1, it is merged into master. Depending how much CI power you have, PR#2 (and any other PR in queue) can be automatically built again on top of new master to verify it wont break anything. You can do it lazily too and just re-check PR#2 once it gets approved by human - like other comment mentioned, CI coordinates and serializes all merges into master making sure master is always green.

Joky 8y ago
That's not very scalable: with a team of 100 developers merging on average 100 PRs a day, you have lot of concurrency. Imagine everyone want to merge at the same time, only one can, the 99 others have to re-run the build/tests. Then only one merges and 98 others have to re-run the build tests, etc. On a project where the build/tests can take hours, this becomes difficult to justify... And then, there is the "I merged a fix into the release branch, which auto-merge into master, the fix built and tested OK in the release branch but not when propagated to master".