[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 01/01: hydra: services: Fix Cuirass configuration.
From: |
Ludovic Courtès |
Subject: |
Re: 01/01: hydra: services: Fix Cuirass configuration. |
Date: |
Mon, 23 Jul 2018 14:58:10 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Hey!
Clément Lassieur <address@hidden> skribis:
> 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.
Yeah I know, terrible.
> 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.
In practice I have to admit that I add, remove, or modify specs through
the sqlite3 command line, and that’s okayish (did you know that SQL was
initially designed to be *the* user interface to the database? :-)).
Another approach would be to have part of our database available in Git
instead of in an actual database. So Cuirass would pull its specs from
a Git repo and that’s it. That’s less work than writing an HTTP
interface, and that’s more flexible/convenient.
>> 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!
OK. Well that’s good enough for now!
Thanks for explaining!
Ludo’.