Hello David, David Craven <da...@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
