Hacker News new | past | comments | ask | show | jobs | submit login

bors solves a similar problem, but we've found that enterprises require a lot of additional features to get their dev teams to actually use it, so we've focused on those to make this production-ready. Specifically:

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.

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.

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)

4. We offer a whole host of useful analytics to show you merge bottlenecks. We initially just put these as a nice-to-have, but we've now got customers who use us specifically because of these analytics!

We're also constantly adding new features based on customer requests (for instance, the flaky test features we're piloting originally came from customer requests we kept hearing over and over!). Speaking of which, if there's something you'd like to see that you don't currently get from your existing system/bors, do let me know :)




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

[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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: