Re: 01/01: hydra: services: Fix Cuirass configuration.

[Clément Lassieur]

Heya :-)

Ludovic Courtès <address@hidden> writes:

> Thanks a lot for fixing it!  Cuirass is back up and running now on
> berlin.

Yay!

One note though: Cuirass reads the config once, and only adds the
specifications whose name isn't already in the database.  So it would
have worked if you had used '() as a specification list, because the
database was in a consistent state (thanks to the upgrade).

The four specifications I added are totally useless, except for their
names, and the fact that they describe the database.  What I mean is
that if you change them it won't have any effect.  But if you change
their name, Cuirass will think they are new and try to add them to the
database.

This behaviour is terrible, because it means the configuration is non
deterministic.  It would be great to add a mechanism that detects
specification changes, and updates the database accordingly.  But I'm
not sure it's feasible.  Another solution would be to edit the database
through a web interface, à la hydra :-), but that would require a lot of
work.

> One question: could we have a single “guix” input corresponding to
> https://git…/guix.git for the master branch?  I suppose that should work
> in theory?

The inputs can all be named "guix", if that's what you mean.  Actually,
they can all be named the way you want, except the 'guix-modular' ones
that can only be named "guix" or "guix-modular"[1].  I think we should
add an ad-hoc 'key' field to avoid that restriction.  That 'key' field
would be the key used by the evaluator to access the 'guix-checkout'.

As for allowing the same input to be used by several specifications
(that is, a N - N relationship between the Inputs and the Specifications
tables), it is possible, but it would require deep changes: each input
would need to have a associated stamp in the database, and when the
input changes, the evaluation of all its specs would need to be
triggered.  It would be more efficient though, because it would reduce
the number of 'git pull'.

I chose to implement a N - 1 relationship between Inputs and
Specifications because that's how Hydra does, it requires less code
changes, and in most cases several specifications won't use the exact
same inputs.  But we can definitely improve it if you think it's worth
it!

> Anyway the database migration went smoothly and the new schema looks
> much better.  Thank you!

HTH!
Clément

[1]: 
https://git.savannah.gnu.org/cgit/guix.git/tree/build-aux/hydra/guix-modular.scm#n66