max/nix-super
1
0
Fork 0
mirror of https://github.com/privatevoid-net/nix-super.git synced 2024-11-11 08:46:16 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions 1
nix-super/tests/nixos/default.nix

60 lines
1.8 KiB
Nix
Raw Normal View History

Define NixOS tests in `tests/nixos/default.nix` rather than `flake.nix` I think the our `flake.nix` is currently too large and too scary looking. I think this matters --- if Nix cannot dog-food itself in a way that is elegant, why should other people have confidence that their own code can be elegant and easy to maintain? We could do this at many points in time, but I think around now, when we are thinking about stabilizing parts of Flakes, is an especially good time. This is a first step to make the `flake.nix` smaller, and make individual components responsible for their own packaging. I hope we can do this many more follow-ups like it, until the top-level `flake.nix` is very small and just coordinates between other things.
2023-10-06 17:53:01 +03:00
{ lib, nixpkgs, nixpkgsFor }:
let
nixos-lib = import (nixpkgs + "/nixos/lib") { };
# https://nixos.org/manual/nixos/unstable/index.html#sec-calling-nixos-tests
initialize test suite for git fetchers solves #9388 This utilizes nixos vm tests to allow: - writing tests for fetchTree and fetchGit involving actual networking. - writing small independent test cases by automating local and remote repository setup per test case. This adds: - a gitea module setting up a gitea server - a setup module that simplifies writing test cases by automating the repo setup. - a simple git http test case Other improvements: For all nixos tests, add capability of overriding the nix version to test against. This should make it easier to prevent regressions. If a new test is added it can simply be ran against any older nix version without having to backport the test. For example, for running the container tests against nix 2.12.0: `nix build "$(nix eval --raw .#hydraJobs.tests.containers --impure --apply 't: (t.forNix "2.12.0").drvPath')^*" -L`
2023-12-29 10:15:16 +02:00
runNixOSTestFor = system: test:
(nixos-lib.runTest {
imports = [ test ];
hostPkgs = nixpkgsFor.${system}.native;
defaults = {
nixpkgs.pkgs = nixpkgsFor.${system}.native;
nix.checkAllErrors = false;
};
_module.args.nixpkgs = nixpkgs;
_module.args.system = system;
})
// {
# allow running tests against older nix versions via `nix eval --apply`
# Example:
# nix build "$(nix eval --raw --impure .#hydraJobs.tests.fetch-git --apply 't: (t.forNix "2.19.2").drvPath')^*"
forNix = nixVersion: runNixOSTestFor system {
imports = [test];
defaults.nixpkgs.overlays = [(curr: prev: {
nix = (builtins.getFlake "nix/${nixVersion}").packages.${system}.nix;
})];
};
Define NixOS tests in `tests/nixos/default.nix` rather than `flake.nix` I think the our `flake.nix` is currently too large and too scary looking. I think this matters --- if Nix cannot dog-food itself in a way that is elegant, why should other people have confidence that their own code can be elegant and easy to maintain? We could do this at many points in time, but I think around now, when we are thinking about stabilizing parts of Flakes, is an especially good time. This is a first step to make the `flake.nix` smaller, and make individual components responsible for their own packaging. I hope we can do this many more follow-ups like it, until the top-level `flake.nix` is very small and just coordinates between other things.
2023-10-06 17:53:01 +03:00
};
in
{
authorization = runNixOSTestFor "x86_64-linux" ./authorization.nix;
remoteBuilds = runNixOSTestFor "x86_64-linux" ./remote-builds.nix;
libstore/ssh-ng: Fix phase reporting in log files. When doing local builds, we get phase reporting lines in the log file, they look like '@nix {"action":"setPhase","phase":"unpackPhase"}'. With the ssh-ng protocol, we do have access to these messages, but since we are only including messages of type resBuildLogLine in the logs, the phase information does not end up in the log file. The phase reporting could probably be improved altoghether (it looks like it is kind of accidental that these JSON messages for phase reporting show up but others don't, just because they are actually emitted by nixpkgs' stdenv), but as a first step I propose to make ssh-ng behave in the same way as local builds do.
2023-10-31 18:32:09 +02:00
remoteBuildsSshNg = runNixOSTestFor "x86_64-linux" ./remote-builds-ssh-ng.nix;
Define NixOS tests in `tests/nixos/default.nix` rather than `flake.nix` I think the our `flake.nix` is currently too large and too scary looking. I think this matters --- if Nix cannot dog-food itself in a way that is elegant, why should other people have confidence that their own code can be elegant and easy to maintain? We could do this at many points in time, but I think around now, when we are thinking about stabilizing parts of Flakes, is an especially good time. This is a first step to make the `flake.nix` smaller, and make individual components responsible for their own packaging. I hope we can do this many more follow-ups like it, until the top-level `flake.nix` is very small and just coordinates between other things.
2023-10-06 17:53:01 +03:00
nix-copy-closure = runNixOSTestFor "x86_64-linux" ./nix-copy-closure.nix;
nix-copy = runNixOSTestFor "x86_64-linux" ./nix-copy.nix;
nssPreload = runNixOSTestFor "x86_64-linux" ./nss-preload.nix;
githubFlakes = runNixOSTestFor "x86_64-linux" ./github-flakes.nix;
sourcehutFlakes = runNixOSTestFor "x86_64-linux" ./sourcehut-flakes.nix;
tarballFlakes = runNixOSTestFor "x86_64-linux" ./tarball-flakes.nix;
containers = runNixOSTestFor "x86_64-linux" ./containers/containers.nix;
setuid = lib.genAttrs
["i686-linux" "x86_64-linux"]
(system: runNixOSTestFor system ./setuid.nix);
initialize test suite for git fetchers solves #9388 This utilizes nixos vm tests to allow: - writing tests for fetchTree and fetchGit involving actual networking. - writing small independent test cases by automating local and remote repository setup per test case. This adds: - a gitea module setting up a gitea server - a setup module that simplifies writing test cases by automating the repo setup. - a simple git http test case Other improvements: For all nixos tests, add capability of overriding the nix version to test against. This should make it easier to prevent regressions. If a new test is added it can simply be ran against any older nix version without having to backport the test. For example, for running the container tests against nix 2.12.0: `nix build "$(nix eval --raw .#hydraJobs.tests.containers --impure --apply 't: (t.forNix "2.12.0").drvPath')^*" -L`
2023-12-29 10:15:16 +02:00
fetch-git = runNixOSTestFor "x86_64-linux" ./fetch-git;
Define NixOS tests in `tests/nixos/default.nix` rather than `flake.nix` I think the our `flake.nix` is currently too large and too scary looking. I think this matters --- if Nix cannot dog-food itself in a way that is elegant, why should other people have confidence that their own code can be elegant and easy to maintain? We could do this at many points in time, but I think around now, when we are thinking about stabilizing parts of Flakes, is an especially good time. This is a first step to make the `flake.nix` smaller, and make individual components responsible for their own packaging. I hope we can do this many more follow-ups like it, until the top-level `flake.nix` is very small and just coordinates between other things.
2023-10-06 17:53:01 +03:00
}
Reference in a new issue Copy permalink