Andreas Enge <[email protected]> writes:

> We might also have to tackle the elephant in the room, that is, whether
> instead of running two build farms that work so-so, it would be better
> to bundle resources into one. One of the arguments for two build farms
> was that this would help us work on reproducibility; but right now we
> are held back by infrastructure that does not work well enough to even
> solve our daily problems of building out branches and pull requests,
> let alone do everything twice. Or alternatively, assign clear and
> complementary roles to each of the two build farms.

I think the key element here is getting on of these services to build
pull requests.

Both are 80% there, but each has its own set of problems. :-)
Roughly, these are:

  1. PR derivations computed by the Data Service have to be submitted to
     the Build Coordinator:
     <https://codeberg.org/guix/maintenance/issues/24>.

  2. Cuirass support for Forgejo PRs is ready, modulo glitches (example:
     <https://codeberg.org/guix-science/guix-science/pulls/182>) but we
     have yet to test it at the scale of all of Guix.  It currently has
     no bound on the number of builds per PR, which would quickly be
     problematic.

At this point, given this urgency, we might as well consider plain
Forgejo Actions + shell scripts to at least have *something* in place
until one of the two build farms is ready.

The upside is that it’s pretty rewarding to hack on it because CI is
(well, should be) central to our work.  So if anyone reading this is
looking for a way to help, now’s your chance! :-)

Ludo’.

Reply via email to