Hydra

Hydra ist ein Werkzeug für kontinuierliche Integrationstests und Softwarefreigabe, das eine rein funktionale Sprache zur Beschreibung von Build-Jobs und deren Abhängigkeiten verwendet. Kontinuierliche Integration ist eine einfache Technik zur Verbesserung der Qualität des Softwareentwicklungsprozesses. Ein automatisiertes System prüft kontinuierlich oder periodisch den Quellcode eines Projekts, baut ihn, führt Tests durch und erstellt Berichte für die Entwickler. Auf diese Weise werden verschiedene Fehler, die versehentlich in die Codebasis aufgenommen werden könnten, automatisch erkannt.

Die offiziellen Hydra-Server bieten vorgefertigte Binärpakete an, um die Aktualisierungszeit für Nixpgs zu verkürzen: Die Benutzer müssen sie nicht auf ihren eigenen Computern kompilieren.

Das Hydra Handbuch bietet eine Übersicht der Funktionalität und Funktionen von Hydra sowohl als auch eine aktuelle Installationsanleitung.

Installation

Since 2017, hydra is available as a NixOS module and therefore a full deployment can be enabled as easy as

  services.hydra = {
    enable = true;
    hydraURL = "http://localhost:3000"; # externally visible URL
    notificationSender = "hydra@localhost"; # e-mail of hydra service
    # a standalone hydra will require you to unset the buildMachinesFiles list to avoid using a nonexistant /etc/nix/machines
    buildMachinesFiles = [];
    # you will probably also want, otherwise *everything* will be built from scratch
    useSubstitutes = true;
  };

The module will automatically enable postgresql if you do not change the services.hydra.dbi option. Database layout will be created automatically by the hydra service, however keep in mind that some state will be stored in the database and a complete stateless configuration is currently not possible - do your backups.

See nixos-option or the Nixos Options page for all options

Web Configuration

Hydra will provide the web interface at localhost port 3000. However you need to create a new admin user (as unix user hydra) before being able to perform any changes:

# su - hydra
$ hydra-create-user alice --full-name 'Alice Q. User' \
    --email-address 'alice@example.org' --password-prompt --role admin

Virtual machine

If not configured explicitly to do otherwise, Hydra will specify localhost as the default build machine. By default, system features enabling builds to be performed in virtual machines like "kvm" or "nixos-test" are not enabled. Such jobs will be queued indefinitely. Those options can be activated as follows:

{
  nix.buildMachines = [
    { hostName = "localhost";
      system = "x86_64-linux";
      supportedFeatures = ["kvm" "nixos-test" "big-parallel" "benchmark"];
      maxJobs = 8;
    }
  ];
}

This option leads to the file /etc/nix/machines being created. If the hydra service config is still set to buildMachinesFiles = [], then it will be ignored, so remove this option again or add /etc/nix/machines to it.

Flake jobset

Configure jobset the following:

Type: Flake
Flake URI: an URI to a repo containing a Flake like git+https://git.myserver.net/user/repo.git

The Flake output should have the attribute hydraJobs containing an attribute set that may be nested and reference derivations.

A sample Flake output that makes Hydra build all packages could look like this:

{
  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
  };
  outputs = { self, nixpkgs, ... }: {
    packages.x86_64-linux = {
      ...
    };
</div>

    <div lang="en" dir="ltr" class="mw-content-ltr">
hydraJobs = {
      inherit (self)
        packages;
    };
  };
}

Restricted Mode

Hydra evaluates flakes in restricted mode. This prevents access to files outside of the nix store, including those fetched as flake inputs. Update your nix.settings.allowed-uris to include URI prefixes from which you expect flake inputs to be fetched:

nix.settings.allowed-uris = [
  "github:"
  "git+https://github.com/"
  "git+ssh://github.com/"
];

Build a single Package from nixpkgs

Right now it is not possible to build a single package from nixpkgs with just that input. You will need to provide a supplementary repository which defines what to build. For examples you can check the hydra-example by makefu and in the Hydra Manual.

Imperative Building

These steps are required to build the hello package.

log into hydra after creating a user with hydra-create-user
create new project

identifier: example-hello
display name: example-hello

Actions -> Create jobset

identifier: hello
Nix expression: release.nix in hydra-example -> will evaluate the file release.nix in the given input
check interval: 60
scheduling shares: 1
Inputs:

Input Name	Type	Value	Note
nixpkgs	git checkout	https://github.com/nixos/nixpkgs nixos-21.11	will check out branch nixos-21.11, will be made available to the nix expression via `<nixpkgs>`.
hydra-example	git checkout	https://github.com/makefu/hydra-example	hydra-example is used by the jobset as input, `release.nix` is in the root directory

After creation, the jobset should be in the evaluation phase where inputs will be fetched. This phase may take some time as the complete nixpkgs repository needs to be downloaded before continuing. The result of the evaluation should be a single job which will get built.

Declarative Building

Since 2016, hydra supports declarative creation of jobsets. Check out the example repository and description by Shea Levy.

Hydra Internals

Definitions

This subsection provides an overview of the Hydra-specific definitions and how to configure them.

Project

A cluster of Jobs which are all coming from a single input (like a git checkout), the first thing you will need to create. Every Job should be able to be built independently from another. Most of the time the project maps to a single repository like nixpkgs. It is comparable to the project definition in Jenkins

Jobset

Eine Liste von Jobs, die ausgeführt werden sollen. Oft passt ein Jobset zu einem bestimmten Branch (master, staging, stable). Ein Jobset wird durch seine Eingaben definiert und wird ausgelöst, wenn sich diese Eingaben ändern, z.B. wenn ein neuer Commit zu einem Branch hinzugefügt wird. Jobsets können voneinander abhängen

Job

Ein Closure, welches als Teil eines Jobsatzes erstellt wird (wie ein einzelnes Paket, ISO-Image oder Tarball)

Release Set

Definiert alle Jobs, die in Ihrem Release beschrieben sind. Konventionell wird eine Datei namens release.nix verwendet. Eine ausführliche Beschreibung der Struktur finden Sie im Hydra Handbuch für Build Recipes.

Evaluation

The process of interpreting nix code into a list of .drv files. These files are the build recipes for all related outputs. You can introspect these files by running nix show-derivation nixpkgs.hello

Build

Instantiation of a Job which is being triggered by being part of the release set

Known Issues

hydra-queue-runner sometimes gets stuck even with builds are in the queue, and the builds are not scheduled. The issue is being tracked here. In the meantime, a workaround is to add a cron job that regularly restarts the hydra-queue-runner systemd service. Possible fix: [1]
If you see error: unexpected end-of-file it can mean multiple things, some of them are:

You have a miss-match between nix versions on the Hydra server and the builder
It can also mean that hydra-queue-runner needs privileges on the build server. Reference: [2]

The default timeout for git operations is 600 seconds [3], which might cause fetches of large repositories like nixos/nixpkgs to fail: error fetching latest change from git repo at `https://github.com/nixos/nixpkgs': timeout. The timeout can be increased with the following configuration.nix snippet:

{
  services.hydra.extraConfig = ''
    <git-input>
      timeout = 3600
    </git-input>
  '';
}

Hydra for NixOS releases

Hydra is used for managing official Nix project releases. The project Hydra server: https://hydra.nixos.org/

Some Hydra trackers for Nix projects:

Resources