Hey! Clément Lassieur <[email protected]> skribis:
> Ludovic Courtès <[email protected]> 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’.
