This makes it easy to set environment variables for the Hydra server
(for example, your configuration.nix can use readFile to read an API
token to upload build results somewhere).
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Oops, forgot to add this in f75509099a.
This is necessary because we actually want to run the preStart script as
root (because it chmod/chowns stuff and also needs to create the
database using PostgreSQL's superuser) and the actual creation of the
database as user hydra.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The su binary is now in a separate output of the shadow package and
isn't included in the main output path anymore.
But instead of changing the call to use pkgs.su, we're now entirely
dropping the dependency because systemd is already able to execute
processes under a specific user by itself.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
In the dashboard and on the job page, indicate whether the job appears
in the latest jobset eval. That way, the user gets some indication if
a job has accidentally disappeared (e.g. due to an evaluation error).
Use the following in your hydra.conf to make your instance a
private Hydra instance (public is the default):
private 1
Currently, this will not allow you to use the API, channels
and the binary cache when running in private mode. We will add
solutions for these functionalities later.
This requires adding the following to hydra.conf:
binary_cache_key_name = <key-name>
binary_cache_private_key_file = <path-to-private-key>
e.g.
binary_cache_key_name = hydra.nixos.org-1
binary_cache_private_key_file = /home/hydra/cache-key.sec
All successful, non-garbage-collected builds in the evaluation are
passed in a attribute set. So if you declare a Hydra input named
‘foo’ of type ‘eval’, you get a set with members ‘foo.<jobname>’. For
instance, if you passed a Nixpkgs eval as an input named ‘nixpkgs’,
then you could get the Firefox build for x86_64-linux as
‘nixpkgs.firefox.x86_64-linux’.
Inputs of type ‘eval’ can be specified in three ways:
* As the number of the evaluation.
* As a jobset identifier (‘<project>:<jobset>’), which will yield the
latest finished evaluation of that jobset. Note that there is no
guarantee that any job in that evaluation has succeeded, so it might
not be very useful.
* As a job identifier (‘<project>:<jobset>:<job>’), which will yield
the latest finished evaluation of that jobset in which <job>
succeeded. In conjunction with aggregate jobs, this allows you to
make sure that the evaluation contains the desired builds.
