Hydra: Difference between revisions
imported>Makefu hydraSender -> notificationSender |
imported>Makefu No edit summary |
||
Line 16: | Line 16: | ||
hydraURL = "http://localhost:3000"; # externally visible URL | hydraURL = "http://localhost:3000"; # externally visible URL | ||
notificationSender = "hydra@localhost"; # e-mail of hydra service | 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 | # you will probably also want, otherwise *everything* will be built from scratch | ||
useSubstitutes = true; | |||
}; | }; | ||
</syntaxHighlight> | </syntaxHighlight> |
Revision as of 14:22, 26 February 2018
Hydra is a tool for continuous integration testing and software release that uses a purely functional language to describe build jobs and their dependencies. Continuous integration is a simple technique to improve the quality of the software development process. An automated system continuously or periodically checks out the source code of a project, builds it, runs tests, and produces reports for the developers. Thus, various errors that might accidentally be committed into the code base are automatically caught.
From the Hydra manual
The Hydra manual provides an overview of the functionality and features of hydra, as well as an up-to-date installation guide.
Usage
Installation
Since 2017, hydra is available as a NixOS module and therefore a full deployment can be enabled as easy as
services.postgresql.enable = true;
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;
};
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 Config
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:
$ hydra-create-user alice --full-name 'Alice Q. User' \
--email-address 'alice@example.org' --password foobar --role admin
Build a single Package from nixpkgs
TODO
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
- Job Set:
A list of jobs which will be run. Often a Jobset fits to a certain branch (master, staging, stable). A jobset is defined by its inputs and will trigger if these inputs change, e.g. like a new commit onto a branch is added. Job sets may depend on each other
- Job:
A closure which will be built as part of a jobset (like a single package, iso image or tarball)
- Release Set:
Defines all the jobs which are described in your release. By convention a file calledrelease.nix
is being used. See the Hydra manual for Build Recipes for a thorough description of the structure.
- Build:
Instantiation of a Job which is being triggered by being part of the release set