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.
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.