You can use one of the mainstream continuous integration tools, such as GitLab-CI. To do that, you need to make sure you run jobs in a Docker image or virtual machine that has Guix installed. If we were to do that in the case of Guile, we’d have a job that runs a shell command like this one:
guix build -L $PWD/.guix/modules email@example.com
Doing this works great and has the advantage of being easy to achieve on your favorite CI platform.
That said, you’ll really get the most of it by using Cuirass, a CI tool designed for and tightly integrated with Guix. Using it is more work than using a hosted CI tool because you first need to set it up, but that setup phase is greatly simplified if you use its Guix System service (see Continuous Integration in GNU Guix Reference Manual). Going back to our example, we give Cuirass a spec file that goes like this:
It differs from what you’d do with other CI tools in two important ways:
guix. Indeed, our own
guile package depends on many
packages provided by the
guix channel—GCC, the GNU libc,
libffi, and so on. Changes to packages from the
guix channel can
potentially influence our
guile build and this is something we’d
like to see as soon as possible as Guile developers.
transparently get pre-built binaries! (see Substitutes in GNU
Guix Reference Manual, for background info on substitutes.)
From a developer’s viewpoint, the end result is this
status page listing
evaluations: each evaluation is a combination of commits of the
guile channels providing a number of
jobs—one job per package defined in guile-package.scm
times the number of target architectures.
As for substitutes, they come for free! As an example, since our
guile jobset is built on ci.guix.gnu.org, which runs
guix publish (see Invoking guix publish in GNU Guix
Reference Manual) in addition to Cuirass, one automatically gets
guile builds from ci.guix.gnu.org; no additional
work is needed for that.