Making sure the repository doesn't break, automatically - https://people.gnome.org/~federico/blog/making-sure-the-repository-doesnt-break.html
@alatiera I want that soooooo much.
@federicomena
// Reached mastodon limit
This has some advantages and disadvantages as documented here:
http://aturon.github.io/2018/03
/19/bors/
TLDR, we would like the ability to have separate pipelines depending on the MR status
@alatiera hehehe, a victim of its own success? :)
I wonder how things would look with a faster build - librsvg is tiny in comparison to rustc, of course.
(I think bors could do wonders for Cairo, FWIW)
@federicomena What about porting https://github.com/bors-ng/bors-ng ?
@bb010g huh, no idea. How would that be different?
@federicomena bors-ng is specifically made to be runnable over any repository with little effort, and thus is configured with a bors.toml file (documented here: https://bors.tech/documentation/ ). It's also written in Elixir instead of Python, so you get that nice BEAM reliability. The main issue I'd see is that it's tailored to be a GitHub Application, but you might be able to refactor in backends and add GitLab. (A quick glance at the directory structure makes me think it wouldn't be too horrible.)
@bb010g thanks, this is quite interesting!
I'll post an update to the blog. I'm not sure if this is a yak I want to shave... :)
@federicomena you probably want to point people to bors-ng; it has a much more scalable algorithm (optimistic batches with bisection) https://bors.tech/
@graydon what could make one repo not scale? Long build times / lots of contributors / things like that?
@federicomena Yes, cycle time and commit volume. Speaking from experience these become significant enough bottlenecks that people who are cynical or impatient about the plan will argue for switching back to "merge first, test later". It's astounding but I've seen this play out repeatedly now. Like people who "don't need type systems" and use compile time as their lever in the argument. Failure to do whole system accounting on development process, time lost to broken trees.
@graydon Preach it. It's wanting to go back to not wearing safety equipment.
Do you know how it "felt" when Rust switched from the original Bors to whatever new implementation? I kind of want to use homu-gitlab as soon as possible if it already would work for gitlab.gnome.org, instead of shaving the yak of porting bors-ng to gitlab.
I guess I haven't used what Rust uses from a maintainer's viewpoint; I just like the "tree never breaks" mechanics.
@federicomena No, I have no idea about homu; they switched to it after I left. As far as I know it's fine. Original-generation bors was about as stupid and crude as I could make it. Stateless cron job every 5 minutes.
@graydon thanks! The stateless model *is* very appealing.
@federicomena For clarification, the GitlabCI can do all of those too, Our problem is that we want to have separate pipelines so we don't overload the runners.
The bors feature we miss is the following:
* You open a merge request
* A small pipeline is run to make sure it builds
* if so, MR is annotated with ready for review
* When the MR is approved for merge it's put on a Queue.
* Bors picks things from the Queue rebase them to master and
run A bigger Pipeline.
* If it succeeds it merges