Re: using Cuirass to track a guix packages' git

[Mathieu Lirzin]

Jan Nieuwenhuizen <address@hidden> writes:

> Mathieu Lirzin writes:
>
> Hi Mathieu!
>
>>> I had some trouble with the #:no-compile? option, it's currently
>>> specified twice.  On the Cuirass side I think it should be a property
>>> of the spec, but it seems it gets only passed as part of the
>>> arguments.  Ideas?
>>
>> OK, I think I got it.  With the idea to move to a client/server
>> architecture in the future, Cuirass uses the database to keep track of
>> the specifications (in a weird way).  When new specifications are added
>> with --specifications, they are first put in the database before being
>> fetched back with the previously added ones.  As a consequence if a key
>> in the specification is not handle when adding the spec to the database
>> in 'db-add-specification' procedure, then it will be ignored.
>>
>> Does it make sense?
>
> That makes sense; thanks, I understand.
>
>> If yes, then I guess that patch 2 and 3 can easily be adapted to use
>> only '#:no-compile?' as a property.
>
> Yes, that works.  I was wondering if using #:compile? would be better,
> but I kind of like the sqlite default of `0' being translated to #f and
> I did not want to change the default setting.  WDYT?

Intuitively I would prefer "#:compile?" but both are OK, so we can stick
with "#:no-compile?" if that's more convenient.

>>> Subject: [PATCH 3/4] tests: track cuirass' git.
>>> +(define-public cuirass-git
>>> +  (package
>>> +    (name "cuirass-git")
>>
>> Since this is a package definition of Cuirass, would it make sense to
>> rename it to "guix.scm" recommended in Guix manual?
>
> Sure, done.
>
>> Is the (ci) module definition required?
>
> Not in guix.scm per se, so I have removed it there.
>
> However, in tracking of a packages' git it is necessary for the package
> description being available to guix build, which AIUI means that its
> package definition must be available in a module in the
> GUIX_PACKAGE_PATH.
>
> I am using this Guix package definition of Cuirass in the
> tests/hello-git.scm test, tracking Cuirass's git.  So, therefore we need
> something like the (ci) module in guix/.  This now works by pre-inst-env
> adding the guix/ sub-directory to the GUIX_PACKAGE_PATH.

OK.

>> Can you send the updated patches?
>
> Sure, find attached.

Pushed with minor cosmetic changes.  :)

>  I have refrained from describing this Git-tracking
> feature in README because it would need a version of these patches to go
> in first.  When it works with your notabug git source url, we can add a
> description. to help people going.

Given the current state of Cuirass, I think it is OK to not provide
documentation while experimenting.

>> I think you have done an amazing job.  Thank you!
>
> Thanks!  I'd really love to get a working Guix-based ci system and
> Cuirass is already very close to the minimal set that I need.  I have
> a working patch to add building of VMs (a la hydra/guix-system.scm) but
> it needs a bit of cleanup work.

Nice!

> I'm wondering about the status of the http integration.  I have played a
> bit with what there is now but do not understand how to use it or what
> steps would be needed, what direction to go, to help getting a minimal
> web view up.

There is a basic Guile Web server which is runnable via
'run-cuirass-server' procedure.  There is only one JSON ressource which
is accessible from "/specifications" and "/jobsets" routes.  To use the
server you have to parameterize the '%package-database' parameter to
point to an SQLite file with specifications in it.

What needs to be done is to provide more JSON ressources (inspired by
Hydra API) by translating request to SQL queries.  A command line
interface would be a nice addition too.

Thanks.

-- 
Mathieu Lirzin