load on the Hydra build farm (where it's unnecessary anyway because
it has a fast connection to the build machines). In any case,
compression can be enabled by using the `-C' option to ssh.
doesn't exist. The Debian packages don't include the manifests
directory, so nix-channel would silently skip doing a nix-pull,
resulting in everything being built from source. Thanks to Juan
Pedro Bolívar Puente.
giving jobs to the first machine until it hits its job limit, then
the second machine and so on. This should improve utilisation of
the Hydra build farm a lot. Also take an optional speed factor
into account to cause fast machines to be preferred over slower
machines with a similar load.
(that is, call the build hook with a certain interval until it
accepts the build).
* build-remote.pl was totally broken: for all system types other than
the local system type, it would send all builds to the *first*
machine of the appropriate type.
sure that it works as expected when you pass it a derivation. That
is, we have to make sure that all build-time dependencies are built,
and that they are all in the input closure (otherwise remote builds
might fail, for example). This is ensured at instantiation time by
adding all derivations and their sources to inputDrvs and inputSrcs.
downloaded files; rather, check the hash of the unpacked store
path.
When the server produces bzipped NAR archives on demand (like Hydra
does), the hash of the file is not known in advance; it's streamed
from the server. Thus the manifest doesn't contain a hash for the
bzipped NAR archive. However, the server does know the hash of the
*uncompressed* NAR archive (the "NarHash" field), since it's stored
in the Nix database (nix-store -q --hash /nix/store/bla). So we use
that instead for checking the integrity of the download.
scan for runtime dependencies (i.e. the local machine shouldn't do a
scan that the remote machine has already done). Also pipe directly
into `nix-store --import': don't use a temporary file.
(e.g. an SSH connection problem) and permanent failures (i.e. the
builder failed). This matters to Hydra (it wants to know whether it
makes sense to retry a build).
makes more sense for the build farm, otherwise every nix-store
invocation will lead to at least one local build. Will come up with
a better solution later...
necessary that at least one build hook doesn't return "postpone",
otherwise nix-store will barf ("waiting for a build slot, yet there
are no running children"). So inform the build hook when this is
the case, so that it can start a build even when that would exceed
the maximum load on a machine.
list like
root@example.org x86_64-linux /root/.ssh/id_buildfarm 1
root@example.org i686-darwin /root/.ssh/id_buildfarm 1
This is possible when the Nix installation on example.org itself has
remote builds enabled.
derivation should be a source rather than a derivation dependency of
the call to the NAR derivation. Otherwise the derivation (and all
its dependencies) will be built as a side-effect, which may not even
succeed.
