5.1 With the local Guix daemon

This is the default build mechanism. Once the build jobs are evaluated, they are sent to the local Guix daemon. Cuirass then listens to the Guix daemon output to detect the various build events.

While this mode doesn’t require any particular configuration, it doesn’t scale well. The scheduling decisions of the Guix daemon are opaque and often suboptimal.

When Cuirass is used to build a large amount of jobs, the remote build mechanism described below should be preferred.

5.2 With the remote build mechanism.

This mode is harder to setup but scales way better. This is the build mode that is used on the GNU Guix build farm at https://ci.guix.gnu.org. The build jobs are not submitted to the local Guix daemon. Instead, a remote server dispatches build requests to the connect remote workers, according to the build priorities.

The remote server and the connected workers communicate using ZMQ over TCP. The workers are able to discover the remote server using Avahi.

The built items are exchanged as substitutes (see Substitutes in Guix) by spawning Guix publish servers both on the remote server and on each connected remote worker.

It can be enabled this way:

• Start the cuirass register process with the build-remote command line argument, see Invocation. This way, the registration process does not submit the new build jobs to the local Guix daemon.
• Start the cuirass remote-server process to dispatch the build jobs to the connected workers.
• Start at least one cuirass remote-worker process on any machine of the local network to actually perform the builds and report their status.

Note that some Cuirass features are only available when using this build mode. That’s the case for:

• The build priority support.
• The notification mechanism, see Notifications.
• The transmission of timeout and max-silent-time package properties to the Guix daemon.
• The live build log mechanism of the Web interface.
• The workers status page of the Web inferface accessible at ‘http://cuirass-url/workers’.

The easiest way to setup such an infrastructure is to rely on the GNU Guix Cuirass services definitions (see Continuous Integration in Guix).

Alternatively, there is a systemd service unit file installed at $CUIRASS_PREFIX/lib/systemd/system/cuirass-remote-worker.service to launch the cuirass remote-worker on systems which use systemd. It can be installed and enabled as follows:

sudo install -o root -g root -m 644 \
     $CUIRASS_PREFIX/lib/systemd/system/cuirass-remote-worker.service \
     /etc/systemd/system
sudo systemctl enable cuirass-remote-worker.service
sudo systemctl start cuirass-remote-worker.service