Re: [GSoC] Continuous integration tool à la Hydra.

[Mathieu Lirzin <mthl@gnu.org>]

Hello David,

David Craven <david@craven.ch> writes:

> Are you already working on a package/service for guix?

This would indeed be the goal, however I am not there yet.

> I'd like to deploy it to my server to avoid silly mistakes
> like in my last two pushes to master...
>
> Does it rebuild from commit individually or only HEAD?
> This would be nice to check for rebase mistakes where
> HEAD builds but a commit doesn't.

That would make sense as an option, however the current model is
simplistic and only evaluates the new HEAD commit.

> Does it already support building packages for all guix
> supported systems?

For now, you have to modify the 'gnu-system.scm' file to your needs to
achieve that.  basically you need to define another "subset" case in
'gnu-system.scm' and adjust the '#:arguments' value in the job
specification.

> ```
> (define (local-file file)
> ;; In the common case jobs will be defined relative to the repository.
> ;; However for testing purpose use local gnu-system.scm instead.
> (string-append (dirname (current-filename)) "/" file))
> (define hello-master
> `((#:name . "guix")
> (#:url . "git://git.savannah.gnu.org/guix.git")
> (#:load-path . ".")
> (#:file . ,(local-file "gnu-system.scm"))
> (#:proc . hydra-jobs)
> (#:arguments (subset . "hello"))
> (#:branch . "master")))
> (list hello-master)
> ```
>
> Can I also define custom jobs like running guix --rounds=2 and
> guix lint?

Likewise.  However this would require more work.  :)

I guess the future approach will be to define both the scheme code
running on the client side and on the build (remote) side in the job
specification.  I mean something similar to what Guix is doing for its
package definitions.  The details are not defined yet.

Thanks for your questions.

-- 
Mathieu Lirzin