5 ms·

This is exactly the kind of workflow that Bors (https://github.com/bors-ng/bors-ng https://github.com/bors-ng/bors-ng) automates. In addition to Bors, there ar

This is exactly the kind of workflow that Bors (https://github.com/bors-ng/bors-ng 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-nrsrose/51 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 https://graydon2.dreamwidth.org/1597.html Disclaimer: I have contributed code to Bors.

jacktli 7y ago
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.
- metajack 7y ago
  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.
  - Ericson2314 7y ago
    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.
omeze 7y ago
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.
- chrisseaton 7y ago
  > 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?
  - draw_down 7y ago
    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.
  - BiteCode_dev 7y ago
    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.
  - omeze 7y ago
    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.
- metajack 7y ago
demosito666 7y ago
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.
- ljm 7y ago
  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.
  - clintonb 7y ago
    Travis tests both the development branch and the merge/integration branch. https://docs.travis-ci.com/user/pull-requests/#double-builds-on-pull-requests https://docs.travis-ci.com/user/pull-requests/#double-builds...
- DougBTX 7y ago
  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.

jacktli 7y ago

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.

metajack 7y ago
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.
- Ericson2314 7y ago
  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.

omeze 7y ago

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.

chrisseaton 7y ago
> 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?
- draw_down 7y ago
  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.
- BiteCode_dev 7y ago
  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.
- omeze 7y ago
  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.
metajack 7y ago

demosito666 7y ago

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.

ljm 7y ago
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.
- clintonb 7y ago
  Travis tests both the development branch and the merge/integration branch. https://docs.travis-ci.com/user/pull-requests/#double-builds-on-pull-requests https://docs.travis-ci.com/user/pull-requests/#double-builds...
DougBTX 7y ago
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.