continuous build: merge to master on green

[andychu]

Now that we have reliable continuous build, it would be nice to keep master green.

#742 exposed this.

Knowing the build is broken after the fact is good, but there's an obvious hole ...

---

I don't know how to do this myself, but if anyone has ideas please chime in :-)

[jyn514]

It sounds like you want @bors: https://github.com/rust-lang/homu

[andychu]

Hm interesting. It looks like bors and homu are separate projects.

Do you know what the difference is? I guess Rust migrated to / created homu because bors wasn't cutting it in some way?

[andychu]

Oh I guess homu is because bors is written for buildbot and they don't use buildbot anymore?

I remember that Mozilla was using buildbot a long time ago, so it sorta makes sense ....

[jyn514]

There's a long history and I'm not sure of all of it ... If you're interested I'll ask around some more, I think bors-ng is the one that's currently recommended, the rust fork has a lot of peculiarities IIRC.

[jyn514]

Yeah this looks much better documented: https://github.com/bors-ng/bors-ng. There is also a bors-rs but it's very experimental.

[andychu]

Hm it all looks kinda complex. I'm inclined to to defer it for awhile (or I would accept a PR if it "just worked")

We should definitely do this eventually, but I think there aren't enough contributors at the moment to justify the work.

(Also these are famous last words, but I don't understand why the whole thing isn't a shell script? We should just push to master2 and then have Travis job with credentials to do the merge to master? We already have some Nix credentials in Travis.)

What started this is that I did indeed leave the master branch broken for a day, which I regret. That is mostly because I didn't think anyone else was pulling at the moment :) But I have learned my lesson and the master branch is much more frequently green now.

(What I would fix is that the one red failure here for Nix is actually OK http://travis-ci.oilshell.org/jobs/

However it doesn't affect the badge on the README.md, so I'm not super concerned.)

[andychu]

After looking a bit more at bors, I can see that one reason it might not be a simple shell script is if you have "concurrent" merges, e.g. lots of PRs open at once, some of which may not be green. But you don't want to "block" the pipeline on one bad commit.

But I think we could get by with a "linear model". e.g. master lags behind may-not-be-green-master.

If there's a broken commit, then the whole thing is held up, which is OK for us, but not for a huge project with tons of committers

[andychu]

Very relevant thread: https://news.ycombinator.com/item?id=21584144

in Chrome they had a "try bot". But again I think that was heavily concurrent, which we don't need now

[andychu]

Actually I now think this is higher priority, because the oil-native translation via mycpp now runs in the continuous build. And I kind of lean on that to test it.

So there is a non-neglible chance that someone will clone when the oil-native build is broken, even if the Python build is mostly what's necessary to change Oil. (Eventually I would like help in translation)

from the HN thread: https://forum.bors.tech/t/other-apps-that-implement-the-nrsrose/51

[andychu]

Merge bot is done with a simple shell script! I don't see any reason this won't work even for a high number of contributors / high concurrency ?

https://github.com/oilshell/oil/blob/master/soil/maybe-merge.sh

https://oilshell.zulipchat.com/#narrow/stream/121539-oil-dev/topic/Creating.20Merge.20Bot

[andychu]

Release awhile ago: https://www.oilshell.org/blog/2022/07/release-0.11.0.html