(Note: near term, this probably isn't a useful idea, as the current GitHub & GitLab proposals aren't proposing the introduction of merge gating, merely advisory testing of PRs, so folks will remain free to merge patches locally and push them up to the master repository. However, I think pre-merge testing is a good idea long term, with approving our own PRs taking the place of pushing directly to the development and maintenance branches) I recently came across an old article [1] by Rust's Graydon Hoare regarding their approach to pre-merge testing of commits using GitHub PRs and Buildbot. Following up on that brought me to a more up to date explanation of their current bot setup [2], and the http://homu.io/ service for running it against a project without hosting your own instance (in our case, if we did run a service like Homu, we'd likely still want to host our own instance, as Mozilla do for Rust and Servo). Similar to OpenStack's Zuul, Homu serialises commits, ensuring that the test suite is passing *before* code lands on the target branch. The relevant differences are that Homu is designed to use GitHub PRs rather than Gerrit reviews as the event source, and Travis CI and Buildbot rather than Jenkins as the CI backends for actually running the integration tests. (Homu is also currently missing Zuul's "speculative test pipeline" feature, which allows it to test multiple commits in parallel on the assumption that most of them will pass due to prior testing in isolation, but has a separate feature that allows PRs to be tagged for inclusion in "rollup" commits that land several changes at once after testing them as a group) The current merge queue for Rust itself can be seen at http://buildbot.rust-lang.org/homu/queue/rust Regards, Nick. [1] http://graydon2.dreamwidth.org/1597.html [2] http://huonw.github.io/blog/2015/03/rust-infrastructure-can-be-your-infrastr... -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia