Hi Clément, Sorry for the delay. Lots of exciting stuff in this message!
Clément Lassieur <clem...@lassieur.org> skribis: > 1. Adding support for multiple inputs. Currently Cuirass only supports > one input per specification, which has to be the Guix git repository. > But one might want inputs for: > - a repository containing the 'proc' that returns the jobs, > - a repository containing extra packages (GUIX_PACKAGE_PATH). > Those inputs would be fetched at INTERVAL as well, and any change would > trigger an evaluation. This is a follow-up of > https://lists.gnu.org/archive/html/guix-patches/2018-06/msg00311.html. Excellent. I think the polling interval should be per input, while we’re at it. > 2. Removing the notion of 'project'. Cuirass really has no project, and > what is called a 'project' is in fact a 'specification' (which Hydra > calls 'jobset'). And what is called a 'jobset' by Cuirass is in fact > the branch of the Guix input. So the patch associates to the name > 'jobset' what it really is: a specification. A consequence is that the > 'jobset' filtering of the API now filters by specification name, and it > is not possible anymore to filter by branch. (But it was useless IMHO.) That makes sense to me. > 3. Allowing any input to be in Guile's %load-path when 'proc' is called. > Usually, the only input that is in Guile's %load-path is Guix. But > someone might want to use a custom library in 'proc'. The alternative > is to just specify the Guix input that should be appended to Guile's > %load-path. > > (I'm unsure about 3., I can't find any real use case. That would just > make it more flexible I guess.) We can also wait until there’s a real use case, it’s often a good idea. :-) > Also, some specification fields (#:load-path-inputs, > #:package-path-inputs, #:proc-input) refer to the inputs by their name, > as Hydra does (with nixExprInput). Nice! > This makes it easy to do configuration mistakes, and would ultimately > require a configuration syntax checker. The only alternative I can > think of involves duplicating the inputs, which isn't good. Good. > I'm sending this email because even though the patches are already done > and they work on my Cuirass instance, there are a few other things to do > before I can send them: > - add a mechanism to update the database, > - update the documentation. > So if you think I'm not on the right track, please let me know as soon > as possible :-) Looks like you’re on the right track. You submitted changes to guix-patches in the meantime so I’ll take a look at these. > I attached my configuration before those patches and the one after them, > so that you can see how the new configuration would look like. The work > in progress is available at > https://git.lassieur.org/cgit/cuirass.git/log/. Neat. > '((#:name . "guix-manifest-savannah") > (#:load-path-inputs . ("guix")) > (#:package-path-inputs . ("packages")) > (#:proc-input . "conf") > (#:proc-path . "guix/cuirass-derivations.scm") > (#:proc . drv-list) > (#:proc-args . ()) > (#:inputs . (((#:name . "guix") > (#:url . "git://git.savannah.gnu.org/guix.git") > (#:load-path . ".") > (#:branch . "master") > (#:no-compile? . #t)) > ((#:name . "conf") > (#:url . "git://git.lassieur.org/emacs.git") > (#:load-path . ".") > (#:branch . "master") > (#:no-compile? . #t)) > ((#:name . "packages") > (#:url . "git://git.lassieur.org/packages.git") > (#:load-path . ".") > (#:branch . "master") > (#:no-compile? . #t))))) Really cool example, and exactly what we were missing from Hydra. Thanks a lot for working on this! Ludo’.