Re: Cuirass changes

[Ludovic Courtès]

Hi Clément,

Sorry for the delay.  Lots of exciting stuff in this message!

Clément Lassieur <address@hidden> 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’.