Simon Tournier <zimon.touto...@gmail.com> writes: >> I would like to see some setup for testing Pull Requests raised on >> Codeberg, although it's not clear to me how to approach this and I want >> to focus on finishing off the work on the existing setup [6]. Some work >> towards this has already happened [7], but I'm not aware this is up an >> running anywhere yet. > > Sorry if I’m out of the scope. Well, I’m not sure to get the picture > between QA, Data Service, and the two build farms bordeaux.guix and > ci.guix.
There's a diagram here which has some information on how things relate to each other: https://qa.guix.gnu.org/README#orgdc0ae66 > If I understand correctly, ci.guix (Cuirass) already implements > something to trigger a build by a Pull Request. And I remember the days > where Data Service was collecting data from Cuirass. > > My question is: in addition to bridging Forgejo with Build Coordinator > so then QA and Data Service, could you point where to look to restore a > bridge between Cuirass and Data Service and/or QA? So collecting data from Cuirass never scaled well, since there can be a lot of builds and if you need to keep checking for status changes, it's really inefficient. When I realised this I did write some code for Cuirass to send build status information to the data service, but I don't think it was used. It's this approach that's used with the build coordinator. > Worded differently, do you a rough estimation about how much work it > would be? Couple of hours? Days? Weeks? Too hard because of some > orthogonal design between Cuirass and Data Service? I don't think it would be too much work to do this. There's some minor issues like whether Failed builds can then go on to start again, personally I prefer the build coordinator model where you can have more than one build for a derivation. Cuirass also has a less strict notion of build failure which I'm not a big fan off, personally I think for a build to fail it should have to at least start (e.g. a build shouldn't fail because the derivation is missing). If you're thinking about this in relation to builds for Pull Requests though, I think it's important to come up with at least a minimally viable plan for how everything should work. Say ci.guix.gnu.org did start doing builds based off of Pull Requests and sending that data to data.qa.guix.gnu.org, the data serivce is not going to be able to do much with that data until it's processed the Pull Request and computed the derivations, and if that is happening, then there's no reason why the qa-frontpage can't be submitting builds to the bordeaux build farm in the same way that it's doing currently, which may mean that not much benefit comes from getting the build information from Cuirass to the data service in the first place.
signature.asc
Description: PGP signature
