guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Cuirass changes


From: Clément Lassieur
Subject: Cuirass changes
Date: Mon, 02 Jul 2018 20:01:28 +0200
User-agent: mu4e 1.0; emacs 26.1

Hi,

I'm currently working on Cuirass, so that it looks a bit more like
Hydra.  The changes include:

1. Adding support for multiple inputs.  Currently Cuirass only supports
one input per specification, which has to be the Guix git repository.
But one might want inputs for:
  - a repository containing the 'proc' that returns the jobs,
  - a repository containing extra packages (GUIX_PACKAGE_PATH).
Those inputs would be fetched at INTERVAL as well, and any change would
trigger an evaluation.  This is a follow-up of
https://lists.gnu.org/archive/html/guix-patches/2018-06/msg00311.html.

2. Removing the notion of 'project'.  Cuirass really has no project, and
what is called a 'project' is in fact a 'specification' (which Hydra
calls 'jobset').  And what is called a 'jobset' by Cuirass is in fact
the branch of the Guix input.  So the patch associates to the name
'jobset' what it really is: a specification.  A consequence is that the
'jobset' filtering of the API now filters by specification name, and it
is not possible anymore to filter by branch.  (But it was useless IMHO.)

3. Allowing any input to be in Guile's %load-path when 'proc' is called.
Usually, the only input that is in Guile's %load-path is Guix.  But
someone might want to use a custom library in 'proc'.  The alternative
is to just specify the Guix input that should be appended to Guile's
%load-path.

(I'm unsure about 3., I can't find any real use case.  That would just
make it more flexible I guess.)

Also, some specification fields (#:load-path-inputs,
#:package-path-inputs, #:proc-input) refer to the inputs by their name,
as Hydra does (with nixExprInput).  This makes it easy to do
configuration mistakes, and would ultimately require a configuration
syntax checker.  The only alternative I can think of involves
duplicating the inputs, which isn't good.

I'm sending this email because even though the patches are already done
and they work on my Cuirass instance, there are a few other things to do
before I can send them:
  - add a mechanism to update the database,
  - update the documentation.
So if you think I'm not on the right track, please let me know as soon
as possible :-)

I attached my configuration before those patches and the one after them,
so that you can see how the new configuration would look like.  The work
in progress is available at
https://git.lassieur.org/cgit/cuirass.git/log/.

Clément

Attachment: old.scm
Description: Binary data

Attachment: new.scm
Description: Binary data


reply via email to

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