[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#31813] [PATCH] evaluate: Use a generic key to identify Cuirass argu
From: |
Clément Lassieur |
Subject: |
[bug#31813] [PATCH] evaluate: Use a generic key to identify Cuirass arguments. |
Date: |
Fri, 15 Jun 2018 01:03:40 +0200 |
User-agent: |
mu4e 1.0; emacs 26.1 |
Heya :-)
Ludovic Courtès <address@hidden> 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?
We need a sure way to distinguish the 'guix-checkout' argument from the
other ones being appended ((systems "x86_64-linux") in our case). We
thought about choosing a more descriptive name, like 'guix-checkout',
but that would require modifying Guix's build-aux/hydra/guix-modular.scm
like this: (which is probably fine)
--8<---------------cut here---------------start------------->8---
(define guix-checkout
(or (assq-ref arguments 'guix) ;Hydra on hydra
- (assq-ref arguments 'guix-modular))) ;Cuirass on berlin
+ (assq-ref arguments 'guix-checkout))) ;Cuirass on berlin
--8<---------------cut here---------------end--------------->8---
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.
> Shouldn’t we instead change the schema along these lines?
>
> 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:
--8<---------------cut here---------------start------------->8---
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
--8<---------------cut here---------------end--------------->8---
and so we would have two (guix-modular, master) pairs, thus conflicting
with the PRIMARY KEY constraint again. Using an auto-incrementing ID
column could work, but I don't like it for the reasons I explained
above.
> Mathieu Othacehe <address@hidden> skribis:
>
>> Thanks to this patch, we are able to build on Cuirass guix package from
>> multiple source repositories (guix-modular-url1, guix-modular-url2, ...)
>>
>> and then guix pull --url=url1 or guix pull --url=url2
>
> Neat! So you have a Cuirass setup that works well for you? I’m asking
> because I’m not fully satisfied with what we have on berlin, but part of
> the issues come from offloading to 20+ machines.
:-) 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.
Clément