First up, this is more of a call for interest than comments on particular work. You’ll see why.
In my presentation at the last US LLVM dev (https://llvm.org/devmtg/2022-11/slides/TechTalk5-WhatDoesItTakeToRunLLVMBuildbots.pdf) I ended with a proposal to move llvm’s testing into pre-commit.
There was a decent amount of interest (some recorded in the notes for the subsequent roundtable Buildbots roundtable notes US LLVM Dev 2022).
Therefore I had planned to have something for folks to look at early this year and start a discussion about the next steps.
Unfortunately due to my personal schedule and other work commitments I haven’t been able to do that and I won’t be able to work on this until around July at the earliest. And ideally, we’d have something prototyped by around the time of the switch to Github PRs late in the year.
So that I am not blocking anyone else, here’s what I had intended to try. I appreciate there will be a lot of debate (perhaps too much) over vague plans like this, but I’d rather be open so others can work on it if they wish.
We already have build bots and there are other projects that use them in pre-commit. For example, Buildbot itself (though I am not 100% sure because Github has hidden the older checks for example here Github hook: Include "previous filename" key in list of files by DavidSpickett · Pull Request #6807 · buildbot/buildbot · GitHub).
Even if no one has done it, I’m sure we can use a webhook to trigger from Github somehow.
Most importantly, pre-commit is basically an extension of builds on demand. So the first thing I’d build is a way to manually ask a bot to build a particular PR. Then build on top of that.
The minimum demo system would be:
- Some simple repo with a single python script that for example prints the value of an environment variable (so you know it ran on the right machine).
- A few buildbots with different values of that variable set.
- A command on the Github side that can trigger a build on a specific bot.
- Some way to report those results back to Github. A URL at first, a Github native status box even better.
Then you can experiment by saying “/buildbot build buildbot_with_1” and seeing results on the PR.
Perhaps later one could add commands like “/buildbot owner buildbot_with_1”, quality of life features.
There’s a whole mess here about access control and preventing effectively denial of service attacks using this, but I figure that’s for a later stage (and Github does have some features for that e.g. a maintainer must approve checks for first time contributors).
At some point you could start running it on a fork of llvm to approximate the real experience.
You would need:
- A Github repo.
- A Buildbot master.
- A few build bots connected to that (I would expect that it’s possible to make all these docker containers on a single host).
This is again vague because I haven’t had the time to do the research, but:
- Rust. I know they have a lot of automation, do they have anything like this?
- If there are Github add ons like this, can we just use those?
- This post Buildbots roundtable notes US LLVM Dev 2022 - #15 by kwk from @kwk talks about this very sort of system. Like me they are probably busy with other things but it would be great to not duplicate effort here.
- The Linaro buildbot monitor shows how to get bot status using the API (monitor - llvm/linaro-scripts.git - [no description]).
I think it would be relatively easy to prototype an on demand bot system for Github PRs, but I don’t have the time to do the work for the next few months. If anyone else agrees and has the time, I don’t want to stand in their way.
I don’t think that putting any effort into Phabriactor makes sense right now either, Github is the future.
There are alternatives to Buildbot such as Buildkite, used very successfully by libcxx. I personally wanted to explore keeping the existing infrastructure first, but ultimately have not made up my mind on that. I welcome someone trying Github PR → Buildkite integration (in fact it probably has official plugins).
I am still very much into the idea of pre-commit testing, so I will put time in where I can find it. Including pursuing this proposal if it has not progressed by that time.
So let me know:
- What do you think of the proposed first prototype step?
- Do you have other things you’d rather try?
- Do you already use something like this in another project?
- Would the pre-commit topic benefit from a wider discussion now, or later when there are prototypes we can reference?
cc @luken-google @sqlbyme who I had talked to over email about this.