[bug#31813] [PATCH] evaluate: Use a generic key to identify Cuirass arguments.

[ludo@gnu.org (Ludovic Courtès)]

Hello Clément & Mathieu,

Trying to take a step back and look at how Hydra does things…

Clément Lassieur <clement@lassieur.org> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>>>>> @@ -98,7 +99,7 @@ building things during evaluation~%")
>>>>>                  (proc    (module-ref %user-module proc-name))
>>>>>                  (commit  (assq-ref spec #:current-commit))
>>>>>                  (name    (assq-ref spec #:name))
>>>>> -                (args    `((,(string->symbol name)
>>>>> +                (args    `((guix
>>>>>                              (revision . ,commit)
>>>>>                              (file-name . ,source))
>>>>>                             ,@(or (assq-ref spec #:arguments) '())))
>>>>
>>>> If we do that, then everything is called ‘guix’.
>>>
>>> Why is it a problem?
>>
>> In theory you can have several inputs (checkouts) to a given jobset, and
>> they need to have different names so that you can distinguish among
>> them.

For the record, this calling convention comes from Hydra.  In Hydra, a
“jobset” can have several “inputs”, and they all show up in this ‘args’
list, like:

  ((INPUT1 . PROPERTIES) (INPUT2 . PROPERTIES) …)

where INPUT1 is the famous name shown above.  (See
<https://github.com/NixOS/hydra/blob/master/src/script/hydra-eval-guile-jobs.in>.)

> And anyway if we force the argument key to 'guix', 'guix-checkout' or
> 'guix-modular', it wouldn't prevent us to add other inputs (checkouts)
> later, I think.

It would prevent us from distinguishing between different inputs.
Currently, at least with Hydra, we can do:

  (assoc-ref args 'some-input)

and get the file-name, revision, etc. properties corresponding to
‘some-input’.

So I think we should preserve this API.

The problem we have though is that Cuirass has no notion of “input”.  In
Hydra’s schema, there’s ‘JobsetInputs’ (that’s where we get the input
name from in the ‘args’ alist above), which is separate from ‘Jobset’
(roughly equivalent to ‘Specifications’ in Cuirass.)

  https://github.com/NixOS/hydra/blob/master/src/sql/hydra.sql

Perhaps what we should do is introduce an ‘Input’ table to begin with,
and have ‘Specifications’ refer to one or more of these.

How does that sound?

We can apply your patch in the meantime, so that we can effectively have
several ‘guix-modular’ jobs for example, but what I mean to say is that
it can only be a temporary workaround for a flaw that needs to be fixed.

Thanks for your patience.  :-)

Ludo’.