>Your CI tool should perform a local merge of your branch to the main branch and run the build and tests against that. Your branch can then be automatically merged if the main branch does not change in the meantime. If it does change, the CI checks should be run again until your code can be safely merged. If your CI tools does not support this kind of workflow, change your tool.
4th step should not happen. A cool feature I am implementing into fire.ci now is that it will trigger a new build every time the main branch moves forward until the safe merge happens. If you have fast builds I don't expect this to take more than 2 builds each time (or you have a huuuuge team working on the repo). What do you think?
* PR1 is merged with main branch commit N: build OK. PR1 is merged creating main branch commit N+1
* PR2 is merged the same way creating commit N+2
* PR3 build started at the same time as PR2 build, so using main branch commit N+1
* By the time PR3 build is finished and green, head of main branch is commit N+2. So it's not safe to merge
* A new build is automatically started for the merge of PR3 and main branch commit N+2. If it's green, it is merged, created main branch commit N+3.
See what I mean? (and obviously I can't figure out how to make bullets in this editor sorry ...)
With a build lasting 30 minutes, cases like PR3 above are more likely to happen. But then it doesn't really matter: the build tool will just run builds until it merges. The real issue here is the delayed feedback for the developers: if you are interrupted every 30 minutes with some build status (green or red), it's quite a waste of time daily in terms of context switching.
What CI tool and Git provider are you using? Lately I've worked with a team with a build of 28 minutes using TFS VSTS. We got the build down under 10 minutes using conditional builds (tests ran only if some folders have changed).
And now that I look at your question again: yes. If all 23 builds were green and one person merges, then it would trigger a build on the remaining 22. The thing being that you probably shouldn't have 23 PRs lying around (probably waiting for code review).
Yeah I think what you are suggesting might work if team follows * merge PR asap * keep build time down to n mins.
But its extremely common in big projects to have atleast 20 prs open with long build.
kubernetes has like 1100 open prs atm ( each pr with 5 25 min builds). What should a project like k8s do for CI ? would require insane computing power to launch 5000 builds for every merge.
k8s is open source, which is a different setup: you can't just merge in anything that comes in. In commercial projects though, even with a large team, you should be able to trust any team member to contribute to the main branch in the right way. Mistakes and errors should be caught by the CI build.
Getting from here to there probably requires a transition phase. In the long run though, if the time spared/lost waiting for PRs, developers context switching, resolving conflicts and dealing with errors (that will appear anyway) is invested into improving the quality and speed of automated tests, you end up in a much better place.
I'm not saying it's an easy thing, but in my opinion this is what development teams should strive for.