Gitlab has a fairly conventional Continuous Integration system: you push some commits, the CI pipelines build the code and presumably run the test suite, and later you can know if this succeeded of failed.
But by the time something fails, the broken code is already in the public repository.
The Rust community uses Bors, a bot that prevents this from happening:
-
You push some commits and submit a merge request.
-
A human looks at your merge request; they may tell you to make changes, or they may tell Bors that your request is approved for merging.
-
Bors looks for approved merge requests. It merges each into a temporary branch and waits for the CI pipeline to run there. If CI passes, Bors automatically merges to master. If CI fails, Bors annotates the merge request with the failure, and the main repository stays working.
Bors also tells you if the mainline has moved forward and there's a merge conflict. In that case you need to do a rebase yourself; the repository stays working in the meantime.
This leads to a very fair, very transparent process for contributors and for maintainers. For all the details, watch Emily Dunham's presentation on Rust's community automation (transcript).
For a description of where Bors came from, read Graydon Hoare's blog.
Bors evolved into Homu and it is what Rust and Servo use currently. However, Homu depends on Github.
I just found out that there is a port of Homu for Gitlab. Would anyone care to set it up?
Update: Two people have suggested porting Bors-ng to Gitlab instead, for scalability reasons.