(no title)
jpulec | 5 years ago
Basically, you can add a label to a PR in github and it will then queue it up to be merged once all the required checks pass, and it keeps queued PRs "up-to-date".
It's made a little money, but not much.
Github recently rolled out a feature at Github Universe that has overlap, so I'm guessing it won't get much more traction.
A few lessons I learned: - Especially when building on a platform, make sure you have the right niche. In this case, it probably has a wide enough audience that Github decided it was worth it to build as part of the platform. - Like any engineer, I spent too long building and let scope creep delay me from launching.
All in all, it's pretty cheap (read: basically free) to run, but I probably committed somewhere over 120 hours on it.
TheDong|5 years ago
There was also homu, which predated bors and also did more or less the exact same thing.
Does your thing have any features that differentiate it from what bors does?
jpulec|5 years ago
Beyond that, there are a couple of things that I don't believe bors has.
A big one that I built for myself was the idea of supporting "working hours", i.e. only merge code during this timeframe.
For example, one company I worked for had some pretty flaky tests. Unfortunately, what would happen is we would have several PRs get reviewed and then use a tool like bors to enqueue them. Inevitably, some queued PR would have a failed check for this flaky test.
Fast forward to the weekend and a completely different developer would merge a hotfix into master. Unfortunately, a side effect would be that a tool like bors would try to merge the head commit into the PR with the flaky test, and now it passes! So it gets deployed at a random unexpected time, which isn't what we wanted.
steve_taylor|5 years ago