21–30 of 71 posts
This is where merge queues come into play which have a variety of names (merge queue, submit queue, merge train, etc)
I have a write up on merge queues [0] that goes into other benefits (e.g. speeding up PR builds), design considerations and their trade offs, and a comparison of various implementations.
Like others said, "merge queue" is the solution. GitHub's one has been in beta for many months now.
There are also dedicated companies doing this like https://mergify.com/
But there's several tricky aspects like "what if I want some commit to jump in front of queue?", compliance etc.
Due to the multitude of requirements and off-the-shelf solutions being somehow limited, infra folks in my place are considering building a custom solution :)
Check out something like Bors, which implements a paradigm that fixes this class of issue: https://github.com/bors-ng/bors-ng (Homepage: https://bors.tech/ )
Check out something like Bors, which implements a paradigm that fixes this class of issue: https://github.com/bors-ng/bors-ng (Homepage: https://bors.tech/ )
Does bors stand for something? what does the ng stand for? (I wasn't able to find out while googling.)
Sounds like you want to implement something like merge trains?[0] [0]: https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-tr...
https://github.blog/changelog/2021-10-27-pull-request-merge-...
Is it possible that the solution is to look at why there is such a high frequency of commits by different devs into the same main branch? Rather than look for a technical solution I would explore process and culture changes, such as having the various devs making all the different commits start pairing.
Sounds like you want to implement something like merge trains?[0] [0]: https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-tr...
E.g. when merging A, B and C. C might have no conflict with master or A but it has a conflict with B. Now for the queuing to work A -> B -> C it will have to know somehow how to patch C to fit on top of B.
Maybe B breaks if it is not working after merged into A, and then the queue becomes A -> C -> B (modified), now B probably needs a patch to merge cleanly on C?
Check out something like Bors, which implements a paradigm that fixes this class of issue: https://github.com/bors-ng/bors-ng (Homepage: https://bors.tech/ )
OP’s numbers are 120 commits per hour and 5 minute test run, I’m wondering if adopting bors would necessarily reduce that to 12 commits per hour.