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?

>> Subject: [PATCH 1/4] cuirass: optionally support using of substitutes.

> OK.

Thanks!

>> Subject: [PATCH 2/4] cuirass: support tracking of a guix package's git.

> OK with the #no-compile? fix described above.

Ok, new version attached.

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

>> +(list
>> + `((#:name . ,(url->file-name cuirass-checkout))
>> +   (#:url . ,cuirass-git)
>> +   (#:branch . "master")
>> +   (#:no-compile? . #t)
>> +   (#:load-path . ,guix-checkout)
>> +   (#:proc . guix-jobs)
>> +   (#:file . ,(local-file "guix-track-git.scm"))
>> +   (#:arguments (name . "cuirass-git") (no-compile? . #t) (url . ,cuirass-git))))
>> -- 
>> 2.10.0

> OK with the #no-compile? fix described above.

Ok, done.

>> Subject: [PATCH 4/4] cuirass: handle build failure.

> OK.

Great!

> Can you send the updated patches?

Sure, find attached.  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.

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

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.

Greetings,
Jan