[Top][All Lists]

[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
  - it is inconvenient to use guix-modular.scm with several different
  - 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

> 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 @@
>  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

--8<---------------cut here---------------start------------->8---
sqlite> select * from specifications;
--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

> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]