Hacker News Reader

Comment by DilumAluthge | Hacker News Reader

This is exactly the kind of workflow that Bors (https://github.com/bors-ng/bors-ng) automates.

In addition to Bors, there are a number of apps and services that automate this kind of workflow. Here is an incomplete list: https://forum.bors.tech/t/other-apps-that-implement-the-nrsr...

Edited to add: Graydon Hoare (creator of Rust) called this the Not Rocket Science Rule Of Software Engineering (NRSROSE): "automatically maintain a repository of code that always passes all the tests" - https://graydon2.dreamwidth.org/1597.html

Disclaimer: I have contributed code to Bors.

View on HN

Bors when introduced at my workplace was summarily disabled after 2 separate incidents where it was improperly applying commit messages (which we patched internally) and improperly applying patches (at which point we disabled it and explored other solutions). Combined with the merge latency overhead, I would be extremely hesitant to advocate running it at scale.

> Bors when introduced at my workplace was summarily disabled after 2 separate incidents where it was improperly applying commit messages

Seems a bit extreme to discard something after finding two bugs. Could you have fixed them instead?

Nope, that happening once is bad enough. Those aren't bugs like "oh shoot, my icon is the wrong color". It's really, really important that source control is not lying to you, or things will get very difficult very quickly.

The problem is not the bugs, it's that it was probably recommended to them as a reliable solution, loosing them hours of work. This can't build trust, especially for such an important part of infrastructure: you'll always wonder when it's going to hit you next.

We did fix one bug, but after the 2nd incident decided that using a tool that silently corrupts your repository is not worth the marginal benefit it provides against alternative more naive solutions. Most companies run post-merge checks so in the event of a bad merge, the offending commit can be isolated and reverted, or have a cron running at a regular cadence to isolate the issue to a set of commits. Having your repo reflect developer’s patches is really table stakes for a tool like this anyway.

At this point there are like 4 implementations of Graydon's bors. Which one did you use?

The Servo and Rust projects have used a bors* for many years and have had few problems.

* Servo uses the https://github.com/servo/homu fork of the Homu rewrite of Graydon's original code, and Rust uses a slightly different fork at https://github.com/rust-lang/homu.

The limitation of Bors for us was throughput, we were more interested in testing multiple simultaneous pull requests merging at the same time, rather than testing against the latest master.

With our CI times and PR volume, by the time any CI run completes, master would have drastically changed.

Sequentializing landing so that you can ensure passing tests is the main feature of bors. The normal GitHub CI flow is already what you wanted apparently.

In a bors workflow, bors is the only thing allowed to push to master, so master cannot get out of date.

The Rust projects solves throughput with rollups, which are semi-automated. It would be nice if someone would write fully automated rollup support into a bors, but alas, no one has tried that I know of.

You don't need absolute sequentiality for bors's guarantees. You can speculatively build and try to merge multiple PRs in parallel even though only one will "win". That's fine and not thundering herd stupidity of your build system is incremental so you can share work.

None of this is new at all, btw, I'm just regurgitating MVCC from postgresql.

I've read the description, but I fail to understand how this is different from just merging current master into the PR and running integration on that before merging in back into master? This can be done with 10 lines of groovy in Jenkins.

Also the exact workflow described with staging branch and batch merge is probably another 20-30 lines.

This is what Travis CI did/does and I have not seen another CI platform offer the same.

Travis runs your test suite on the merge commit, not the head of the branch.

Travis tests both the development branch and the merge/integration branch.

https://docs.travis-ci.com/user/pull-requests/#double-builds...

That process assumes nothing gets merged during the integration test run. The script could check to see if the target branch has changed in the mean time, and fail the merge if it has, then I think it would be the same.

Reply on news.ycombinator.com