JakeHillion/nixpkgs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
ef80b6324b
nixpkgs/pkgs/development/tools/misc/hydra/default.nix

41 lines
1.2 KiB
Nix
Raw Normal View History

hydra*: add `passthru.tests` to reference VM-tests
2020-04-15 21:14:20 +01:00
{ fetchFromGitHub, nixStable, callPackage, nixFlakes, fetchpatch, nixosTests }:
hydra: 2020-02-06 -> 2020-03-{24,27} Upgrades Hydra to the latest master/flake branch. To perform this upgrade, it's needed to do a non-trivial db-migration which provides a massive performance-improvement[1]. The basic ideas behind multi-step upgrades of services between NixOS versions have been gathered already[2]. For further context it's recommended to read this first. Basically, the following steps are needed: * Upgrade to a non-breaking version of Hydra with the db-changes (columns are still nullable here). If `system.stateVersion` is set to something older than 20.03, the package will be selected automatically, otherwise `pkgs.hydra-migration` needs to be used. * Run `hydra-backfill-ids` on the server. * Deploy either `pkgs.hydra-unstable` (for Hydra master) or `pkgs.hydra-flakes` (for flakes-support) to activate the optimization. The steps are also documented in the release-notes and in the module using `warnings`. `pkgs.hydra` has been removed as latest Hydra doesn't compile with `pkgs.nixStable` and to ensure a graceful migration using the newly introduced packages. To verify the approach, a simple vm-test has been added which verifies the migration steps. [1] https://github.com/NixOS/hydra/pull/711 [2] https://github.com/NixOS/nixpkgs/pull/82353#issuecomment-598269471
2020-03-27 21:09:13 +00:00
{
# Package for phase-1 of the db migration for Hydra.
# https://github.com/NixOS/hydra/pull/711
hydra-migration = callPackage ./common.nix {
version = "2020-02-10";
src = fetchFromGitHub {
owner = "NixOS";
repo = "hydra";
rev = "add4f610ce6f206fb44702b5a894d877b3a30e3a";
sha256 = "1d8hdgjx2ys0zmixi2ydmimdq7ml20h1ji4amwawcyw59kssh6l3";
};
nix = nixStable;
migration = true;
hydra*: add `passthru.tests` to reference VM-tests
2020-04-15 21:14:20 +01:00
tests = {
db-migration = nixosTests.hydra-db-migration.mig;
basic = nixosTests.hydra.hydra-migration;
};
Add hydra package and its NixOS module. This was originally removed in d4d0e449d7b96704eeaa2570255fb41c85c49613. The intent was not to maintain hydra expression at two places. Nowadays we have enough devs to maintain this despite copy/pasta. This should encourage more people to use Hydra, which is a really great piece of software together with Nix. Tested a deploy using https://github.com/peti/hydra-tutorial
2016-06-01 20:02:58 +01:00
};
hydra: 2020-03-24 -> 2020-04-07 Also removed `pkgs.hydra-flakes` since flake-support has been merged into master[1]. Because of that, `pkgs.hydra-unstable` is now compiled against `pkgs.nixFlakes` and currently requires a patch since Hydra's master doesn't compile[2] atm. [1] https://github.com/NixOS/hydra/pull/730 [2] https://github.com/NixOS/hydra/pull/732
2020-04-06 00:13:07 +01:00
# Hydra from latest master branch. Contains breaking changes,
hydra: 2020-02-06 -> 2020-03-{24,27} Upgrades Hydra to the latest master/flake branch. To perform this upgrade, it's needed to do a non-trivial db-migration which provides a massive performance-improvement[1]. The basic ideas behind multi-step upgrades of services between NixOS versions have been gathered already[2]. For further context it's recommended to read this first. Basically, the following steps are needed: * Upgrade to a non-breaking version of Hydra with the db-changes (columns are still nullable here). If `system.stateVersion` is set to something older than 20.03, the package will be selected automatically, otherwise `pkgs.hydra-migration` needs to be used. * Run `hydra-backfill-ids` on the server. * Deploy either `pkgs.hydra-unstable` (for Hydra master) or `pkgs.hydra-flakes` (for flakes-support) to activate the optimization. The steps are also documented in the release-notes and in the module using `warnings`. `pkgs.hydra` has been removed as latest Hydra doesn't compile with `pkgs.nixStable` and to ensure a graceful migration using the newly introduced packages. To verify the approach, a simple vm-test has been added which verifies the migration steps. [1] https://github.com/NixOS/hydra/pull/711 [2] https://github.com/NixOS/nixpkgs/pull/82353#issuecomment-598269471
2020-03-27 21:09:13 +00:00
# so when having an older version, `pkgs.hydra-migration` should be deployed first.
hydra-unstable = callPackage ./common.nix {
hydra-unstable: 2020-04-07 -> 2020-04-16
2020-04-16 00:01:08 +01:00
version = "2020-04-16";
hydra: 2020-02-06 -> 2020-03-{24,27} Upgrades Hydra to the latest master/flake branch. To perform this upgrade, it's needed to do a non-trivial db-migration which provides a massive performance-improvement[1]. The basic ideas behind multi-step upgrades of services between NixOS versions have been gathered already[2]. For further context it's recommended to read this first. Basically, the following steps are needed: * Upgrade to a non-breaking version of Hydra with the db-changes (columns are still nullable here). If `system.stateVersion` is set to something older than 20.03, the package will be selected automatically, otherwise `pkgs.hydra-migration` needs to be used. * Run `hydra-backfill-ids` on the server. * Deploy either `pkgs.hydra-unstable` (for Hydra master) or `pkgs.hydra-flakes` (for flakes-support) to activate the optimization. The steps are also documented in the release-notes and in the module using `warnings`. `pkgs.hydra` has been removed as latest Hydra doesn't compile with `pkgs.nixStable` and to ensure a graceful migration using the newly introduced packages. To verify the approach, a simple vm-test has been added which verifies the migration steps. [1] https://github.com/NixOS/hydra/pull/711 [2] https://github.com/NixOS/nixpkgs/pull/82353#issuecomment-598269471
2020-03-27 21:09:13 +00:00
src = fetchFromGitHub {
owner = "NixOS";
repo = "hydra";
hydra-unstable: 2020-04-07 -> 2020-04-16
2020-04-16 00:01:08 +01:00
rev = "87837f1d82904bf48e11b5641258b6be2f663c3b";
sha256 = "1vs3lyfyafsl7wbpmycv7c3n9n2rkrswp65msb6q1iskgpvr96d5";
hydra: 2020-02-06 -> 2020-03-{24,27} Upgrades Hydra to the latest master/flake branch. To perform this upgrade, it's needed to do a non-trivial db-migration which provides a massive performance-improvement[1]. The basic ideas behind multi-step upgrades of services between NixOS versions have been gathered already[2]. For further context it's recommended to read this first. Basically, the following steps are needed: * Upgrade to a non-breaking version of Hydra with the db-changes (columns are still nullable here). If `system.stateVersion` is set to something older than 20.03, the package will be selected automatically, otherwise `pkgs.hydra-migration` needs to be used. * Run `hydra-backfill-ids` on the server. * Deploy either `pkgs.hydra-unstable` (for Hydra master) or `pkgs.hydra-flakes` (for flakes-support) to activate the optimization. The steps are also documented in the release-notes and in the module using `warnings`. `pkgs.hydra` has been removed as latest Hydra doesn't compile with `pkgs.nixStable` and to ensure a graceful migration using the newly introduced packages. To verify the approach, a simple vm-test has been added which verifies the migration steps. [1] https://github.com/NixOS/hydra/pull/711 [2] https://github.com/NixOS/nixpkgs/pull/82353#issuecomment-598269471
2020-03-27 21:09:13 +00:00
};
nix = nixFlakes;
hydra*: add `passthru.tests` to reference VM-tests
2020-04-15 21:14:20 +01:00
tests = {
db-migration = nixosTests.hydra-db-migration.mig;
basic = nixosTests.hydra.hydra-unstable;
};
Add hydra package and its NixOS module. This was originally removed in d4d0e449d7b96704eeaa2570255fb41c85c49613. The intent was not to maintain hydra expression at two places. Nowadays we have enough devs to maintain this despite copy/pasta. This should encourage more people to use Hydra, which is a really great piece of software together with Nix. Tested a deploy using https://github.com/peti/hydra-tutorial
2016-06-01 20:02:58 +01:00
};
hydra: 2017-11-21 -> 2018-08-07 This bumps Hydra to the latest revision available. As Hydra doesn't have a release model (and therefore no tags) ATM, the derivation will pin against the actual git revision and the date of the commit in the derivation name. Additionally the following changes have been made: * Dropped `postUnpack` phase. It is useful when working with the Hydra source (and no dirty changes shall be used in `release.nix`, but is has no use in `nixpkgs`). * Added myself as maintainer to have more folks available in case of future breakage. * Implemented support for Nix 2.0 and `unstable` (currently 2.1): Since 1672bcd230447f1ce0c3291950bdd9a662cee974 in NixOS/nix the evaluator differentiates between `settings` and `evalSettings`. Previously `restrictEval` in `hydra-eval-jobs.cc` has been set in `settings`, this doesn't work anymore in Nix 2.1 and is therefore incompatible to Nix 2.0 on an API level. To resolve this, the flag `isGreaterNix20` parses the version string of `pkgs.nix` and applies a patch if nix.version<=2.0. Furthermore the Hydra build with Nix 2.1 requires `boost` as build input which is not needed for Nix 2.0. To avoid unnecessary increase in the closure size this library will only used as build input for nix.version>2.0. * Fixed the NixOS test for `hydra`: disabled binary cache to allow sandbox builds (otherwise it would query `cache.nixos.org` during the Hydra build inside the test). Additionally the trivial.nix jobset required simplification (as done in NixOS/hydra, e.g. tests/api-test.nix) as bash is not available in the build sandbox as builder (even when adding pkgs.bash to systemPackages). The easiest workaround to confirm a the functionality of a jobset without importing nixpkgs is to use the default shell /bin/sh which is mounted from `pkgs.busybox` into the build env (https://github.com/NixOS/nixpkgs/pull/44841#discussion_r209751972) in the VM and a named pipe to create $out. Closes #44044
2018-08-09 21:32:27 +01:00
}
Reference in New Issue Copy Permalink