We're a >200 people company that's been using bors-ng for more than 4 years now for a monorepo. It's been a joy to use Bors! I'd thought I'd just chime in a little here:
1. We focus on being "no-maintenance", since our primary value prop to customers is "you won't have to spend eng resources on merge problems any more". This means: a one-click "set and forget" install, no additional config files to maintain or DSL to learn, unlike bors.
Bors was a breeze to set up and has been super stable and easy to upgrade. We used their Docker container and you need a PostgreSQL database.
2. We have all the security and access-control features you'd want (we're Soc2 compliant, offer on-prem etc). This is important since the product interacts with our customers' source code.
For a monorepo you can get really far using Github's CODEOWNERS file and requiring an approval in bors.toml.
3. We offer various customizations on merge workflows to help our customers optimize the exact parameters they care about (eg: developer wait time vs CI costs vs time to identity bad PRs in a batch, optimistic merge heuristics etc)
Nice! One issue we've seen is that a large backlog of PRs that needs to be merged, combined with a failing PR, is that bifurcations can easily build up a large backlog. We've looked at various different strategies to cope with that[1].
Above said, I really think the _real_ solution to handling large backlogs really lies in speeding up the CI build, not adding even more complexity to handle a backlog. This includes adding caching à-la Earthly[2] et al., but also moving away from heavy integration/system tests etc.
Comments
We're a >200 people company that's been using bors-ng for more than 4 years now for a monorepo. It's been a joy to use Bors! I'd thought I'd just chime in a little here:
Bors was a breeze to set up and has been super stable and easy to upgrade. We used their Docker container and you need a PostgreSQL database.
For a monorepo you can get really far using Github's CODEOWNERS file and requiring an approval in bors.toml.
Nice! One issue we've seen is that a large backlog of PRs that needs to be merged, combined with a failing PR, is that bifurcations can easily build up a large backlog. We've looked at various different strategies to cope with that[1].
[1] https://forum.bors.tech/t/draft-rfc-support-building-batches...
Above said, I really think the _real_ solution to handling large backlogs really lies in speeding up the CI build, not adding even more complexity to handle a backlog. This includes adding caching à-la Earthly[2] et al., but also moving away from heavy integration/system tests etc.
[2] https://earthly.dev