From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37256) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fTbHj-0005h4-8W for guix-patches@gnu.org; Thu, 14 Jun 2018 19:04:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fTbHe-0002GE-5G for guix-patches@gnu.org; Thu, 14 Jun 2018 19:04:07 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:40758) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fTbHe-0002Fn-1e for guix-patches@gnu.org; Thu, 14 Jun 2018 19:04:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fTbHd-0000GW-Np for guix-patches@gnu.org; Thu, 14 Jun 2018 19:04:01 -0400 Subject: [bug#31813] [PATCH] evaluate: Use a generic key to identify Cuirass arguments. Resent-Message-ID: References: <20180613135001.28724-1-clement@lassieur.org> <87po0txfq6.fsf@gnu.org> From: =?UTF-8?Q?Cl=C3=A9ment?= Lassieur In-reply-to: <87po0txfq6.fsf@gnu.org> Date: Fri, 15 Jun 2018 01:03:40 +0200 Message-ID: <87efh9ug1f.fsf@lassieur.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 31813@debbugs.gnu.org Heya :-) Ludovic Court=C3=A8s 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 =E2=80=98guix=E2=80=99. 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=3D100. > Shouldn=E2=80=99t 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; >=20=20 > 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) > ); >=20=20 > CREATE TABLE Stamps ( > > ? > > That way we can have one =E2=80=98guix-modular=E2=80=99 job for each bran= ch, 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/cuira= ss/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/iv4= p56ja708gdwvj85982srqnx2cz056-cuirass-derivations.scm|drv-list|()|master|||1 guix-manifest-clem|git://git.lassieur.org/guix.git|.|/gnu/store/iv4p56ja708= gdwvj85982srqnx2cz056-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 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=3Durl1 or guix pull --url=3Durl2 > > Neat! So you have a Cuirass setup that works well for you? I=E2=80=99m = asking > because I=E2=80=99m 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=C3=A9ment