Re: Tooling for branch workflows

["Ludovic Courtès" <ludo@gnu.org>]

Hello,

Josselin Poiret <dev@jpoiret.xyz> skribis:

> Maybe it would be a good time to create an infrastructure/CI team, and
> set some clear goals for it?  I think it might motivate people (me
> included) to get more involved in GBC development if there is something
> to build towards.

Good idea!

> Also, I kind of agree with Andreas about the bus factor of Cuirass and
> GBC, and wonder whether it makes sense to duplicate development effort
> across both.  It seems to me that Cuirass is working properly as a
> generic CI tool, but it's not super well adapted to Guix, something
> which the GBC seems to be much better at.  Is replacing Cuirass by GBC
> on berlin for Guix CI something that is a future goal, or is it
> understood that Cuirass will be running there for the foreseeable
> future?

Cuirass started as a replacement for Hydra, which is what Nix has been
using, so it’s very similar.  What’s nice is that it’s relatively easy
to set it up to get a bunch of packages built continuously, which is the
major use case for people out there (beyond the project’s own build
farms).

Because the Coordinator itself does nothing but build derivations, one
has to set up some other tool such as the Data Service for that use
case, which may be more difficult (I’m probably biased because I’ve only
set up Cuirass instances).

OTOH, the modularity that the Coordinator/Data Service approach offers
is appealing to me.  It can make it more approachable: one can hack the
Coordinator without worrying about the Data Service.

Anyhow, my suggestion would be to make our infrastructure more robust.
I had to hot-fix Cuirass last week and it was cumbersome because the
test suite only covers basic functionality.  I believe the Coordinator
lacks a test suite, which means it may be harder to modify it (harder to
tell if you broke something) and to get confidence.

So my personal wish list :-) would be improved testing and
documentation.

A longer-term wish: using Spritely Goblins and a modular actor
architecture for those services so we can interact with them through a
rich programming interface and distribute appropriate “capabilities” to
designated developers (a (re)build capability, an “evaluate branch”
capability, etc.).

Ludo’.