Thanks for the link! For those that didn't look at the link, Homu is actually written in Python and not Rust (the website for the project is what's written in Rust).
Berker has actually said he is beginning to look into writing a bot for our needs so he might be interested in this. A quick perusal suggests it probably needs to be modified to understand supporting multiple branches. I also don't know if it supports the fast-forwarding/rebasing commits we want, but I doubt that would be difficult to add. It probably also needs to grow an extension system somehow to support custom NEWS entries for us. But it probably would be really nice for the Python and Rust communities to share some of the infrastructure burden by working on the same tooling (especially if we even consider using their auto-assignment to help get patches reviewed). On Wed, 30 Dec 2015 at 20:21 Nick Coghlan <[email protected]> wrote: > (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-infrastructure/ > > -- > Nick Coghlan | [email protected] | Brisbane, Australia > _______________________________________________ > core-workflow mailing list > [email protected] > https://mail.python.org/mailman/listinfo/core-workflow > This list is governed by the PSF Code of Conduct: > https://www.python.org/psf/codeofconduct >
_______________________________________________ core-workflow mailing list [email protected] https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
