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

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

Hey!

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.

> I don't think the current situation is good because:
>   - a simple mistake from the user gets their build task to silently
>     vanish,
>   - it is inconvenient to use guix-modular.scm with several different
>     specifications,
>   - that #:name key is useless if users can't choose a custom name,
>   - allowing custom names would make it way easier to understand
>     /api/latestbuilds.  For an example with custom names, see
>     https://cuirass.lassieur.org:8081/api/latestbuilds?nr=100.

I agree with all this.  :-)  I think the custom name should appear in
the arguments passed to the build procedure, though.

>> diff --git a/src/schema.sql b/src/schema.sql
>> index 65aebbd..bad2f6d 100644
>> --- a/src/schema.sql
>> +++ b/src/schema.sql
>> @@ -1,7 +1,7 @@
>>  BEGIN TRANSACTION;
>>  
>>  CREATE TABLE Specifications (
>> -  repo_name     TEXT NOT NULL PRIMARY KEY,
>> +  repo_name     TEXT NOT NULL,
>>    url           TEXT NOT NULL,
>>    load_path     TEXT NOT NULL,
>>    file          TEXT NOT NULL,
>> @@ -11,7 +11,8 @@ CREATE TABLE Specifications (
>>    branch        TEXT,
>>    tag           TEXT,
>>    revision      TEXT,
>> -  no_compile_p  INTEGER
>> +  no_compile_p  INTEGER,
>> +  PRIMARY KEY (repo_name, branch)
>>  );
>>  
>>  CREATE TABLE Stamps (
>>
>> ?
>>
>> That way we can have one ‘guix-modular’ job for each branch, for example.
>
> I don't think it would work because our Specifications table looks like
> this:
>
> sqlite> select * from specifications;
> guix-modular-savannah|git://git.savannah.gnu.org/guix.git|.|build-aux/cuirass/guix-modular.scm|cuirass-jobs|((systems "x86_64-linux"))|master|||1
> guix-modular-clem|git://git.lassieur.org/guix.git|.|build-aux/cuirass/guix-modular.scm|cuirass-jobs|((systems "x86_64-linux"))|master|||1
> guix-manifest-savannah|git://git.savannah.gnu.org/guix.git|.|/gnu/store/iv4p56ja708gdwvj85982srqnx2cz056-cuirass-derivations.scm|drv-list|()|master|||1
> guix-manifest-clem|git://git.lassieur.org/guix.git|.|/gnu/store/iv4p56ja708gdwvj85982srqnx2cz056-cuirass-derivations.scm|drv-list|()|master|||1
>
> and so we would have two (guix-modular, master) pairs, thus conflicting
> with the PRIMARY KEY constraint again.

Good point.

> Using an auto-incrementing ID column could work, but I don't like it
> for the reasons I explained above.

You didn’t mention auto-incrementing ID above, did you?  It would seem
like a simple solution to the problem.

> :-)  Yes it works well, but we use it only for 5 machines.  And we only
> build the packages in our manifests (and guix-modular), which isn't
> much.

Heh, pretty cool.  :-)

Thanks,
Ludo’.