Repository navigation
Investigate bors for testing merge commits #530
Description
As I wrote in #526:
One important limitation I just noticed: the CircleCI build only runs on the commit of a PR's branch (what GH Actions labels the
push), it does not automatically run on the merge commit (what Actions callspull_request).This raises the possibility that if a PR is not up to date with
master, all of the CI might go green for a PR, we'll press the big green button, and the resulting merge commit intomasterwill fail. The silver lining is that it will fail, since CircleCI runs on all commits by default.It looks like there's an open (and popular) feature request to add testing on synthetic merge commits to CircleCI directly: https://ideas.circleci.com/ideas/CCI-I-926
This is also another case where using bors would help, since bors creates staging commits that are never behind
master. Maybe it's time to set up bors for this repo?
I have only lightly interacted with bors when submitting patches to rust-lang projects. Let's investigate further to see whether we'd like to enable bors for this repo.
Activity
aturon commentedon May 20, 2020
I will reach out to relevant folks on the Rust side to check in on their current experience around bors and any pitfalls we should be aware of.
aturon commentedon May 21, 2020
So I checked in briefly with the Rust Infra channel, and confirmed a couple of things:
The "bors" bot used by Rust is based on a codebase called "homu", which has been effectively unmaintained for some years. It's used only by Rust and Servo. Adopting literal "bors" from Rust seems unwise. (Further details here)
There is, however, a "bors-ng" (next generation) project which is actively developed and has tools for setting up new projects: https://bors.tech/ (see also the also quite active forum here). That said, I'm not sure how widely used this tool is, so there's still some risk if we get too tied to it.
@acfoltzer lemme know if you'd like me to dig into either of these more deeply!