cafkafk/nixpkgs
cafkafk/nixpkgs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2
nixpkgs/nixos/tests/all-tests.nix

424 lines
20 KiB
Nix
Raw Normal View History

tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
{ system, pkgs, callTest }:
# The return value of this function will be an attrset with arbitrary depth and
# the `anything` returned by callTest at its test leafs.
# The tests not supported by `system` will be replaced with `{}`, so that
meta.tests: rename into passthru.tests Nix currently rejects derivations in `meta` values. This works around that limitation by using `passthru` instead. Closes https://github.com/NixOS/nixpkgs/issues/50230
2018-11-11 14:55:23 +01:00
# `passthru.tests` can contain links to those without breaking on architectures
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
# where said tests are unsupported.
# Example callTest that just extracts the derivation from the test:
# callTest = t: t.test;
with pkgs.lib;
let
discoverTests = val:
if !isAttrs val then val
else if hasAttr "test" val then callTest val
else mapAttrs (n: s: discoverTests s) val;
handleTest = path: args:
discoverTests (import path ({ inherit system pkgs; } // args));
handleTestOn = systems: path: args:
if elem system systems then handleTest path args
else {};
in
{
nixos/3proxy: init
2019-10-10 13:56:05 +02:00
_3proxy = handleTest ./3proxy.nix {};
nixos/tests/acme: don't restrict to x86_64 This was added in aade4e577bbb27f044217c51a006ab6ba544ebb5, but the implementation of the ACME module has been entirely rewritten since then, and the test seems to run fine on AArch64.
2020-03-23 23:12:15 +01:00
acme = handleTest ./acme.nix {};
agda: Added test
2020-04-19 20:01:37 +02:00
agda = handleTest ./agda.nix {};
ammonite: Add test reference, update script
2020-11-04 18:45:20 +01:00
ammonite = handleTest ./ammonite.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
atd = handleTest ./atd.nix {};
avahi = handleTest ./avahi.nix {};
nixosTests.avahi: add avahi-with-resolved This allows testing avahi works with resolved being enabled, as a regression test for https://github.com/NixOS/nixpkgs/pull/99530.
2020-10-11 20:45:25 +02:00
avahi-with-resolved = handleTest ./avahi.nix { networkd = true; };
awscli: Add test
2020-11-25 19:00:41 +01:00
awscli = handleTest ./awscli.nix { };
nixos/tests: add babeld
2019-10-12 01:30:55 +02:00
babeld = handleTest ./babeld.nix {};
bat: Add test
2020-11-28 19:33:16 +01:00
bat = handleTest ./bat.nix {};
nixos/bazarr: init
2020-05-10 12:54:09 +02:00
bazarr = handleTest ./bazarr.nix {};
tests: disable some broken tests and/or restrict to x86_64
2018-11-11 13:27:58 +01:00
bcachefs = handleTestOn ["x86_64-linux"] ./bcachefs.nix {}; # linux-4.18.2018.10.12 is unsupported on aarch64
nixos/beanstalkd: new service for existing package (#55953)
2019-02-22 14:10:02 +01:00
beanstalkd = handleTest ./beanstalkd.nix {};
nixosTests.bees: port to python
2019-11-24 01:10:17 +01:00
bees = handleTest ./bees.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
bind = handleTest ./bind.nix {};
nixos/bitcoind: add tests
2020-07-21 13:43:32 +02:00
bitcoind = handleTest ./bitcoind.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
bittorrent = handleTest ./bittorrent.nix {};
nixos/bitwarden_rs: add test
2020-06-06 12:55:50 +02:00
bitwarden = handleTest ./bitwarden.nix {};
nixos/blockbook-frontend: add tests
2020-06-23 13:09:03 +02:00
blockbook-frontend = handleTest ./blockbook-frontend.nix {};
tests: disable some broken tests and/or restrict to x86_64
2018-11-11 13:27:58 +01:00
boot = handleTestOn ["x86_64-linux"] ./boot.nix {}; # syslinux is unsupported on aarch64
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
boot-stage1 = handleTest ./boot-stage1.nix {};
borgbackup = handleTest ./borgbackup.nix {};
buildbot = handleTest ./buildbot.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
buildkite-agents = handleTest ./buildkite-agents.nix {};
nixos/caddy: add tests (#70778)
2019-10-09 13:32:03 +02:00
caddy = handleTest ./caddy.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
cadvisor = handleTestOn ["x86_64-linux"] ./cadvisor.nix {};
nixos/cage: init Add a cage module to nixos. This can be used to make kiosk-style systems that boot directly to a single application. The user (demo by default) is automatically logged in by this service and the program (xterm by default) is automatically started. This is useful for some embedded, single-user systems where we want automatic booting. To keep the system secure, the user should have limited privileges. Based on the service provided in the Cage wiki here: https://github.com/Hjdskes/cage/wiki/Starting-Cage-on-boot-with-systemd Co-Authored-By: Florian Klink <flokli@flokli.de>
2020-02-19 20:43:48 +01:00
cage = handleTest ./cage.nix {};
cagebreak: init at 1.4.2
2020-10-06 04:18:44 +02:00
cagebreak = handleTest ./cagebreak.nix {};
cassandra: Add passthru.tests
2020-12-09 13:01:56 +01:00
cassandra_2_1 = handleTest ./cassandra.nix { testPackage = pkgs.cassandra_2_1; };
cassandra_2_2 = handleTest ./cassandra.nix { testPackage = pkgs.cassandra_2_2; };
cassandra_3_0 = handleTest ./cassandra.nix { testPackage = pkgs.cassandra_3_0; };
cassandra_3_11 = handleTest ./cassandra.nix { testPackage = pkgs.cassandra_3_11; };
nixos/ceph: Rename old ceph test and add new multi-node test to all-tests.nix
2019-11-01 13:12:18 +01:00
ceph-multi-node = handleTestOn ["x86_64-linux"] ./ceph-multi-node.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
ceph-single-node = handleTestOn ["x86_64-linux"] ./ceph-single-node.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
certmgr = handleTest ./certmgr.nix {};
cfssl = handleTestOn ["x86_64-linux"] ./cfssl.nix {};
charliecloud: 0.12 -> 0.18 (docker + ch-grow support)
2020-08-25 09:44:27 +02:00
charliecloud = handleTest ./charliecloud.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
chromium = (handleTestOn ["x86_64-linux"] ./chromium.nix {}).stable or {};
cjdns = handleTest ./cjdns.nix {};
clickhouse: fix module and package runtime Although the package itself builds fine, the module fails because it tries to log into a non-existant file in `/var/log` which breaks the service. Patching to default config to log to stdout by default fixes the issue. Additionally this is the better solution as NixOS heavily relies on systemd (and thus journald) for logging. Also, the runtime relies on `/etc/localtime` to start, as it's not required by the module system we set UTC as sensitive default when using the module. To ensure that the service's basic functionality is available, a simple NixOS test has been added.
2018-12-19 15:06:53 +01:00
clickhouse = handleTest ./clickhouse.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
cloud-init = handleTest ./cloud-init.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
cockroachdb = handleTestOn ["x86_64-linux"] ./cockroachdb.nix {};
nixos/consul: register test
2019-11-24 15:08:53 +01:00
consul = handleTest ./consul.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
containers-bridge = handleTest ./containers-bridge.nix {};
nixos-containers: Add support for custom nixpkgs argument
2020-04-19 15:41:18 +02:00
containers-custom-pkgs.nix = handleTest ./containers-custom-pkgs.nix {};
nixos/containers: add 'ephemeral' option
2019-08-18 21:37:38 +02:00
containers-ephemeral = handleTest ./containers-ephemeral.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
containers-extra_veth = handleTest ./containers-extra_veth.nix {};
containers-hosts = handleTest ./containers-hosts.nix {};
containers-imperative = handleTest ./containers-imperative.nix {};
nixos/containers-ip: Test both ipv4 and ipv6 in the same script
2019-11-26 00:44:12 +01:00
containers-ip = handleTest ./containers-ip.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
containers-macvlans = handleTest ./containers-macvlans.nix {};
containers-physical_interfaces = handleTest ./containers-physical_interfaces.nix {};
nixosTests.containers-portforward: add to all-tests.nix
2019-12-10 20:34:37 +01:00
containers-portforward = handleTest ./containers-portforward.nix {};
nixosTests.containers-reloadable: expose test This hasn't been available before in nixosTests.
2020-08-23 11:00:09 +02:00
containers-reloadable = handleTest ./containers-reloadable.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
containers-restart_networking = handleTest ./containers-restart_networking.nix {};
containers-tmpfs = handleTest ./containers-tmpfs.nix {};
nixos/convos: add test
2020-06-05 14:54:29 +02:00
convos = handleTest ./convos.nix {};
nixos/corerad: init
2020-01-07 17:52:32 +01:00
corerad = handleTest ./corerad.nix {};
nixos/tests: Reenable couchdb Works just fine in current master
2019-07-24 20:48:43 +02:00
couchdb = handleTest ./couchdb.nix {};
cri-o: add NixOS test via critest Signed-off-by: Sascha Grunert <sgrunert@suse.com>
2020-08-23 16:08:10 +02:00
cri-o = handleTestOn ["x86_64-linux"] ./cri-o.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
deluge = handleTest ./deluge.nix {};
dhparams = handleTest ./dhparams.nix {};
nixosTests.dnscrypt-proxy2: init This removes the old dnscrypt-proxy test.
2020-02-02 00:59:02 +01:00
dnscrypt-proxy2 = handleTestOn ["x86_64-linux"] ./dnscrypt-proxy2.nix {};
nixos/tests/dnscrypt-wrapper: init
2020-04-24 01:33:33 +02:00
dnscrypt-wrapper = handleTestOn ["x86_64-linux"] ./dnscrypt-wrapper {};
nixos/doas: init `doas` is a lighter alternative to `sudo` that "provide[s] 95% of the features of `sudo` with a fraction of the codebase" [1]. I prefer it to `sudo`, so I figured I would add a NixOS module in order for it to be easier to use. The module is based off of the existing `sudo` module. [1] https://github.com/Duncaen/OpenDoas
2020-04-14 05:13:36 +02:00
doas = handleTest ./doas.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
docker = handleTestOn ["x86_64-linux"] ./docker.nix {};
docker-edge = handleTestOn ["x86_64-linux"] ./docker-edge.nix {};
docker-registry = handleTest ./docker-registry.nix {};
docker-tools = handleTestOn ["x86_64-linux"] ./docker-tools.nix {};
nixosTests.docker-tools-cross: init Not everyone has a suitable remote builder set up, so the cross-compilation tests that _include_ running the result are separate. That way, most people can run the majority of the test suite without the extra setup.
2020-12-13 00:33:46 +01:00
docker-tools-cross = handleTestOn ["x86_64-linux" "aarch64-linux"] ./docker-tools-cross.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
docker-tools-overlay = handleTestOn ["x86_64-linux"] ./docker-tools-overlay.nix {};
documize-community: init at 2.2.1 Documize is an open-source alternative for wiki software like Confluence based on Go and EmberJS. This patch adds the sources for the community edition[1], for commercial their paid-plan[2] needs to be used. For commercial use a derivation that bundles the commercial package and contains a `$out/bin/documize` can be passed to `services.documize.enable`. The package compiles the Go sources, the build process also bundles the pre-built frontend from `gui/public` into the binary. The NixOS module generates a simple `systemd` unit which starts the service as a dynamic user, database and a reverse proxy won't be configured. [1] https://www.documize.com/get-started/ [2] https://www.documize.com/pricing/
2019-03-26 19:04:28 +01:00
documize = handleTest ./documize.nix {};
nixos/dokuwiki: init module at 2018-04-22b
2019-12-25 23:04:55 +01:00
dokuwiki = handleTest ./dokuwiki.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
dovecot = handleTest ./dovecot.nix {};
nixosTests.ec2-config: Add to all-tests.nix
2020-02-13 21:31:58 +01:00
ec2-config = (handleTestOn ["x86_64-linux"] ./ec2.nix {}).boot-ec2-config or {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
ec2-nixops = (handleTestOn ["x86_64-linux"] ./ec2.nix {}).boot-ec2-nixops or {};
ecryptfs = handleTest ./ecryptfs.nix {};
nixos/tests: move ejabberd and prosody test to xmpp folder
2019-06-15 11:16:28 +02:00
ejabberd = handleTest ./xmpp/ejabberd.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
elk = handleTestOn ["x86_64-linux"] ./elk.nix {};
nixos/engelsystem: Add test
2020-05-24 14:20:58 +02:00
engelsystem = handleTest ./engelsystem.nix {};
nixos/tests: add enlightenment desktop environment
2020-05-02 16:28:50 +02:00
enlightenment = handleTest ./enlightenment.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
env = handleTest ./env.nix {};
tests/ergo: init
2020-05-24 20:39:23 +02:00
ergo = handleTest ./ergo.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
etcd = handleTestOn ["x86_64-linux"] ./etcd.nix {};
nixos/tests: include the etcd-cluster test in all-tests.nix We seem to have had this test for quite a while, but nothing seems to reference it.
2019-07-10 01:46:21 +02:00
etcd-cluster = handleTestOn ["x86_64-linux"] ./etcd-cluster.nix {};
etesync-dav: 0.20.0 -> 0.30.6
2020-11-30 22:10:07 +01:00
etesync-dav = handleTest ./etesync-dav.nix {};
Fancontrol: add test etc from #70933 (#72065) * lm_sensors: add fancontrol module + nixos test fancontrol is a small script that checks temperature sensors and adapts fan speeds accordingly. It reads a text config file that can be auto-generated by running the pwmconfig wizard on the live system.
2019-10-29 15:06:32 +01:00
fancontrol = handleTest ./fancontrol.nix {};
fcitx: Add test (Unicode input, table input, m17n)
2020-08-26 14:58:37 +02:00
fcitx = handleTest ./fcitx {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
ferm = handleTest ./ferm.nix {};
firefox = handleTest ./firefox.nix {};
nixos/tests/firefox: support running the test with the firefox ESR version Also adds this to the release jobset.
2020-02-10 18:01:47 +01:00
firefox-esr = handleTest ./firefox.nix { esr = true; };
nixos/tests: add test for firejail
2020-08-07 18:45:20 +02:00
firejail = handleTest ./firejail.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
firewall = handleTest ./firewall.nix {};
nixos/fish: generate autocompletions from man pages
2018-12-17 20:12:09 +01:00
fish = handleTest ./fish.nix {};
nixos/flannel: fix flannel nixos test, add test to all-tests.nix
2019-02-12 18:26:08 +01:00
flannel = handleTestOn ["x86_64-linux"] ./flannel.nix {};
fluentd: add simple test
2019-07-29 17:35:27 +02:00
fluentd = handleTest ./fluentd.nix {};
nixos.tests.fontconfig-default-fonts: init Make sure the fonts.enableDefaultFonts option works.
2019-08-29 14:02:20 +02:00
fontconfig-default-fonts = handleTest ./fontconfig-default-fonts.nix {};
nixos/freeswitch: init
2020-01-07 15:53:34 +01:00
freeswitch = handleTest ./freeswitch.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
fsck = handleTest ./fsck.nix {};
ft2-clone: add nixos test
2020-07-29 19:40:38 +02:00
ft2-clone = handleTest ./ft2-clone.nix {};
nixos: add gerrit module Co-authored-by: edef <edef@edef.eu> Co-authored-by: Florian Klink <flokli@flokli.de>
2020-03-05 22:11:28 +01:00
gerrit = handleTest ./gerrit.nix {};
nixos/git-daemon: only create git user if it will be used
2020-02-26 14:05:00 +01:00
gitdaemon = handleTest ./gitdaemon.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
gitea = handleTest ./gitea.nix {};
gitlab = handleTest ./gitlab.nix {};
gitolite = handleTest ./gitolite.nix {};
gitolite: wrap gitolite-shell git wasn't found when used with services.fcgiwrap for http auth
2019-12-05 00:10:57 +01:00
gitolite-fcgiwrap = handleTest ./gitolite-fcgiwrap.nix {};
nixos/glusterfs: add test
2019-08-17 01:28:43 +02:00
glusterfs = handleTest ./glusterfs.nix {};
nixosTests.gnome{xorg}: re-enable on aarch64
2019-08-07 04:01:17 +02:00
gnome3 = handleTest ./gnome3.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
gnome3-xorg = handleTest ./gnome3-xorg.nix {};
go-neb = handleTest ./go-neb.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
gocd-agent = handleTest ./gocd-agent.nix {};
gocd-server = handleTest ./gocd-server.nix {};
nixosTests.graphene: init
2019-05-17 03:29:17 +02:00
google-oslogin = handleTest ./google-oslogin {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
gotify-server = handleTest ./gotify-server.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
grafana = handleTest ./grafana.nix {};
graphite = handleTest ./graphite.nix {};
nixos/graylog: add test Basic test which confirms new inputs can be created and that messages can be sent to a UDP-GELF input using `netcat`. This test requires 4GB of RAM to avoid issues due insufficient memory (please refer to `nixos/tests/elk.nix` for a detailed explanation of the issue) for elasticsearch. Also it's ensured that elasticsearch has an open HTTP port for communication when starting `graylog`. This is a workaround to ensure that all services are started in proper order, even in test environments with less power. However this shouldn't be implemented in the `nixos/graylog` module as this might be harmful when using elasticsearch clusters that require e.g. authentication and/or run on different servers.
2019-07-09 02:01:43 +02:00
graylog = handleTest ./graylog.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
grocy = handleTest ./grocy.nix {};
nixos/tests: add test for grub authentication
2020-06-13 12:06:26 +02:00
grub = handleTest ./grub.nix {};
nixosTests.gvisor: add test for gvisor and gvisor as a Docker runtime
2019-11-27 08:01:46 +01:00
gvisor = handleTest ./gvisor.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
hadoop.hdfs = handleTestOn [ "x86_64-linux" ] ./hadoop/hdfs.nix {};
hadoop.yarn = handleTestOn [ "x86_64-linux" ] ./hadoop/yarn.nix {};
tests: handbrake: test transcoding to MKV and MP4.
2018-11-12 07:45:00 +01:00
handbrake = handleTestOn ["x86_64-linux"] ./handbrake.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
haproxy = handleTest ./haproxy.nix {};
nixos/tests: re-enable hardened test Has been okay since 62623b60d5fed91ac676d6f4a70a12570090d513
2019-01-06 14:04:41 +01:00
hardened = handleTest ./hardened.nix {};
nixos/codimd: rename to hedgedoc CodiMD was renamed to HedgeDoc. The user, group and state directory, will be named hedgedoc instead of codimd, starting with stateVersion "21.03".
2020-11-29 18:51:50 +01:00
hedgedoc = handleTest ./hedgedoc.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
installed-tests = pkgs.recurseIntoAttrs (handleTest ./installed-tests {});
oci-containers = handleTestOn ["x86_64-linux"] ./oci-containers.nix {};
nixos/tests/hibernate: disable for platforms other than x86_64 Due to 9pnet_virtio bugs, /nix is no longer available after hibernation. It happens to work on x86_64, but not on other platforms.
2020-03-26 14:33:57 +01:00
# 9pnet_virtio used to mount /nix partition doesn't support
# hibernation. This test happens to work on x86_64-linux but
# not on other platforms.
hibernate = handleTestOn ["x86_64-linux"] ./hibernate.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
hitch = handleTest ./hitch {};
hocker-fetchdocker = handleTest ./hocker-fetchdocker {};
home-assistant = handleTest ./home-assistant.nix {};
nixos/tests/hostname: init (check system's host name) NixOS currently has issues with setting the FQDN of a system in a way where standard tools work. In order to help with experimentation and avoid regressions, add a test that checks that the hostname is reported as the user wanted it to be. Co-authored-by: Michael Weiss <dev.primeos@gmail.com>
2020-05-12 23:48:27 +02:00
hostname = handleTest ./hostname.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
hound = handleTest ./hound.nix {};
hydra = handleTest ./hydra {};
i3wm = handleTest ./i3wm.nix {};
nixos/icingaweb: Fix module path; Add test
2019-07-07 03:03:59 +02:00
icingaweb2 = handleTest ./icingaweb2.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
iftop = handleTest ./iftop.nix {};
ihatemoney: init at 4.1 plus module and test
2019-09-16 17:08:32 +02:00
ihatemoney = handleTest ./ihatemoney.nix {};
nixos/tests/all-tests.nix: Fix incron test path
2018-11-14 23:51:15 +01:00
incron = handleTest ./incron.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
influxdb = handleTest ./influxdb.nix {};
nixos/system/boot/initrd-openvpn: Add openvpn options for initrd nixos/tests/initrd-openvpn: Add test for openvpn in the initramfs The module in this commit adds new options that allows the integration of an OpenVPN client into the initrd. This can be used e.g. to remotely unlock LUKS devices. This commit also adds two tests for `boot.initrd.network.openvpn`. The first one is a basic test to validate that a failing connection does not prevent the machine from booting. The second test validates that this module actually creates a valid openvpn connection. For this, it spawns three nodes: - The client that uses boot.initrd.network.openvpn - An OpenVPN server that acts as gateway and forwards a port to the client - A node that is external to the OpenVPN network The client connects to the OpenVPN server and spawns a netcat instance that echos a value to every client. Afterwards, the external node checks if it receives this value over the forwarded port on the OpenVPN gateway.
2020-07-01 00:02:56 +02:00
initrd-network-openvpn = handleTest ./initrd-network-openvpn {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
initrd-network-ssh = handleTest ./initrd-network-ssh {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
initrdNetwork = handleTest ./initrd-network.nix {};
nixos/tests: Add test for initrd secrets lz4 compression is excluded because it doesn't work for a reason which remains unclear to me.
2020-12-12 14:39:58 +01:00
initrd-secrets = handleTest ./initrd-secrets.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
installer = handleTest ./installer.nix {};
nixos/iodine: add test
2020-02-02 13:00:00 +01:00
iodine = handleTest ./iodine.nix {};
nixos/ipfs: convert tests to python driver & simplify
2020-05-08 11:48:47 +02:00
ipfs = handleTest ./ipfs.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
ipv6 = handleTest ./ipv6.nix {};
nixos/jackett: Add test for jackett to ensure startup
2019-01-25 07:09:36 +01:00
jackett = handleTest ./jackett.nix {};
nixos/jellyfin: add test to all-tests.nix
2019-05-01 11:57:34 +02:00
jellyfin = handleTest ./jellyfin.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
jenkins = handleTest ./jenkins.nix {};
nixos/jirefeau: add `services.jirafeau` module Signed-off-by: David Wood <david.wood@codeplay.com>
2020-02-06 17:00:19 +01:00
jirafeau = handleTest ./jirafeau.nix {};
nixos/jitsi-meet: init
2020-03-18 04:23:15 +01:00
jitsi-meet = handleTest ./jitsi-meet.nix {};
jq: Add test
2020-11-28 19:42:00 +01:00
jq = handleTest ./jq.nix {};
nixos/k3s: add initial k3s service * nixos/k3s: simplify config expression * nixos/k3s: add config assertions and trim unneeded bits * nixos/k3s: add a test that k3s works; minor module improvements This is a single-node test. Eventually we should also have a multi-node test to verify the agent bit works, but that one's more involved. * nixos/k3s: add option description * nixos/k3s: add defaults for token/serveraddr Now that the assertion enforces their presence, we dont' need to use the typesystem for it. * nixos/k3s: remove unneeded sudo in test * nixos/k3s: add to test list
2020-04-17 16:39:54 +02:00
k3s = handleTest ./k3s.nix {};
kafka: Add test for 2.2 Also add back tests, don't seem broken anymore. This is just fine: nix-build ./nixos/release.nix -A tests.kafka.kafka_2_1.x86_64-linux -A tests.kafka.kafka_2_2.x86_64-linux
2019-04-01 14:39:25 +02:00
kafka = handleTest ./kafka.nix {};
nixos/keepalived: add test
2019-12-22 08:45:31 +01:00
keepalived = handleTest ./keepalived.nix {};
nixos/tests/kerberos: fix evaluation
2019-01-11 05:36:51 +01:00
kerberos = handleTest ./kerberos/default.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
kernel-latest = handleTest ./kernel-latest.nix {};
kernel-lts = handleTest ./kernel-lts.nix {};
linux: Add testing test
2019-04-01 14:31:36 +02:00
kernel-testing = handleTest ./kernel-testing.nix {};
nixos/keycloak: Add support for MySQL and external DBs with SSL - Add support for using MySQL as an option to PostgreSQL. - Enable connecting to external DBs with SSL - Add a database port config option
2020-10-26 15:33:57 +01:00
keycloak = discoverTests (import ./keycloak.nix);
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
keymap = handleTest ./keymap.nix {};
nixos/knot: init
2019-03-13 01:12:56 +01:00
knot = handleTest ./knot.nix {};
nixosTests.krb5: Add to all-tests.nix
2020-02-14 09:56:43 +01:00
krb5 = discoverTests (import ./krb5 {});
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
kubernetes.dns = handleTestOn ["x86_64-linux"] ./kubernetes/dns.nix {};
# kubernetes.e2e should eventually replace kubernetes.rbac when it works
#kubernetes.e2e = handleTestOn ["x86_64-linux"] ./kubernetes/e2e.nix {};
kubernetes.rbac = handleTestOn ["x86_64-linux"] ./kubernetes/rbac.nix {};
nixos/tests/hardened: add latestKernel argument
2020-04-05 01:29:24 +02:00
latestKernel.hardened = handleTest ./hardened.nix { latestKernel = true; };
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
latestKernel.login = handleTest ./login.nix { latestKernel = true; };
leaps = handleTest ./leaps.nix {};
nixos/lidarr: Add test for lidarr to ensure startup
2019-01-24 23:09:42 +01:00
lidarr = handleTest ./lidarr.nix {};
nixos/release-combined: re-enable lightdm test This has been tested in the Pantheon test for a year now and it does fine on hydra.
2019-08-07 00:29:50 +02:00
lightdm = handleTest ./lightdm.nix {};
nixos/limesurvey: add basic nixos test
2019-03-16 13:24:23 +01:00
limesurvey = handleTest ./limesurvey.nix {};
nixos/locate: Add a test
2020-11-24 02:53:21 +01:00
locate = handleTest ./locate.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
login = handleTest ./login.nix {};
nixos/tests: add test for loki
2019-06-27 18:11:09 +02:00
loki = handleTest ./loki.nix {};
lsd: Add test
2020-11-28 19:19:46 +01:00
lsd = handleTest ./lsd.nix {};
lxd: Add tests
2020-06-08 21:33:21 +02:00
lxd = handleTest ./lxd.nix {};
lxd-nftables = handleTest ./lxd-nftables.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
#logstash = handleTest ./logstash.nix {};
lorri: init at version unstable-2019-10-30 Includes user service (nixos/modules/services/development/lorri) that starts on demand.
2019-11-05 11:57:05 +01:00
lorri = handleTest ./lorri/default.nix {};
nixos/tests: add magic-wormhole-mailbox-server
2020-03-30 13:30:05 +02:00
magic-wormhole-mailbox-server = handleTest ./magic-wormhole-mailbox-server.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
magnetico = handleTest ./magnetico.nix {};
nixos/mailcatcher: add nixos test
2019-03-27 12:35:24 +01:00
mailcatcher = handleTest ./mailcatcher.nix {};
mailhog: add simple test
2020-12-17 16:58:57 +01:00
mailhog = handleTest ./mailhog.nix {};
nixos/tests: add check mariadb galera cluster with mariabackup-based SST
2020-04-05 20:39:35 +02:00
mariadb-galera-mariabackup = handleTest ./mysql/mariadb-galera-mariabackup.nix {};
nixos/tests: add check mariadb galera cluster with rsync-based SST
2020-04-05 20:58:27 +02:00
mariadb-galera-rsync = handleTest ./mysql/mariadb-galera-rsync.nix {};
nixos/matomo: add test
2019-10-04 22:38:58 +02:00
matomo = handleTest ./matomo.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
matrix-synapse = handleTest ./matrix-synapse.nix {};
nixos/mediawiki: init service to replace httpd subservice
2019-06-06 03:19:11 +02:00
mediawiki = handleTest ./mediawiki.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
memcached = handleTest ./memcached.nix {};
tests: adding metabase service test
2019-08-18 09:28:16 +02:00
metabase = handleTest ./metabase.nix {};
minecraft: Add test
2020-11-28 18:42:10 +01:00
minecraft = handleTest ./minecraft.nix {};
minecraft-server: Add test
2020-11-28 18:42:46 +01:00
minecraft-server = handleTest ./minecraft-server.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
minidlna = handleTest ./minidlna.nix {};
miniflux: add service
2018-12-21 19:36:58 +01:00
miniflux = handleTest ./miniflux.nix {};
minio: add test to nixos/tests/all-tests.nix
2019-02-05 17:38:34 +01:00
minio = handleTest ./minio.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
misc = handleTest ./misc.nix {};
nixos/moin: init
2019-07-16 01:06:19 +02:00
moinmoin = handleTest ./moinmoin.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
mongodb = handleTest ./mongodb.nix {};
nixos/moodle: init service
2019-06-21 16:09:15 +02:00
moodle = handleTest ./moodle.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
morty = handleTest ./morty.nix {};
nixos/mosquitto: add test
2019-04-24 10:23:13 +02:00
mosquitto = handleTest ./mosquitto.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
mpd = handleTest ./mpd.nix {};
mumble = handleTest ./mumble.nix {};
munin = handleTest ./munin.nix {};
mutableUsers = handleTest ./mutable-users.nix {};
tests: add mxisd to all-tests
2019-05-18 22:18:01 +02:00
mxisd = handleTest ./mxisd.nix {};
nixos/tests: move mysql tests to subfolder
2020-04-02 22:40:55 +02:00
mysql = handleTest ./mysql/mysql.nix {};
mysql-autobackup = handleTest ./mysql/mysql-autobackup.nix {};
mysql-backup = handleTest ./mysql/mysql-backup.nix {};
mysql-replication = handleTest ./mysql/mysql-replication.nix {};
nixos/n8n: init module and test
2020-11-28 18:00:25 +01:00
n8n = handleTest ./n8n.nix {};
nagios: add nixos test
2019-12-30 13:00:00 +01:00
nagios = handleTest ./nagios.nix {};
nano: Add test
2020-11-16 19:59:36 +01:00
nano = handleTest ./nano.nix {};
nar-serve: init at 0.3.0 (#95420) * nar-serve: init at 0.3.0 * nixos/nar-serve: add new module Co-authored-by: zimbatm <zimbatm@zimbatm.com>
2020-11-06 18:59:51 +01:00
nar-serve = handleTest ./nar-serve.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
nat.firewall = handleTest ./nat.nix { withFirewall = true; };
nat.firewall-conntrack = handleTest ./nat.nix { withFirewall = true; withConntrackHelpers = true; };
nat.standalone = handleTest ./nat.nix { withFirewall = false; };
nixos/tests/ncdns: add test
2020-06-07 23:59:12 +02:00
ncdns = handleTest ./ncdns.nix {};
nixos/ndppd: register test
2019-02-03 16:47:01 +01:00
ndppd = handleTest ./ndppd.nix {};
neo4j: add neo4j test
2019-02-01 14:29:54 +01:00
neo4j = handleTest ./neo4j.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
netdata = handleTest ./netdata.nix {};
networking.networkd = handleTest ./networking.nix { networkd = true; };
networking.scripted = handleTest ./networking.nix { networkd = false; };
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
specialisation = handleTest ./specialisation.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
# TODO: put in networking.nix after the test becomes more complete
networkingProxy = handleTest ./networking-proxy.nix {};
nextcloud = handleTest ./nextcloud {};
nexus = handleTest ./nexus.nix {};
nixos/nfs: test nfs with kerberos authentication
2019-11-27 15:37:27 +01:00
# TODO: Test nfsv3 + Kerberos
nfs3 = handleTest ./nfs { version = 3; };
nfs4 = handleTest ./nfs { version = 4; };
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
nghttpx = handleTest ./nghttpx.nix {};
nginx = handleTest ./nginx.nix {};
nginx: test basic auth
2020-10-20 18:05:41 +02:00
nginx-auth = handleTest ./nginx-auth.nix {};
nginx: Clear Last-Modified if ETag is from store This is what I've suspected a while ago[1]: > Heads-up everyone: After testing this in a few production instances, > it seems that some browsers still get cache hits for new store paths > (and changed contents) for some reason. I highly suspect that it might > be due to the last-modified header (as mentioned in [2]). > > Going to test this with last-modified disabled for a little while and > if this is the case I think we should improve that patch by disabling > last-modified if serving from a store path. Much earlier[2] when I reviewed the patch, I wrote this: > Other than that, it looks good to me. > > However, I'm not sure what we should do with Last-Modified header. > From RFC 2616, section 13.3.4: > > - If both an entity tag and a Last-Modified value have been > provided by the origin server, SHOULD use both validators in > cache-conditional requests. This allows both HTTP/1.0 and > HTTP/1.1 caches to respond appropriately. > > I'm a bit nervous about the SHOULD here, as user agents in the wild > could possibly just use Last-Modified and use the cached content > instead. Unfortunately, I didn't pursue this any further back then because @pbogdan noted[3] the following: > Hmm, could they (assuming they are conforming): > > * If an entity tag has been provided by the origin server, MUST > use that entity tag in any cache-conditional request (using If- > Match or If-None-Match). Since running with this patch in some deployments, I found that both Firefox and Chrome/Chromium do NOT re-validate against the ETag if the Last-Modified header is still the same. So I wrote a small NixOS VM test with Geckodriver to have a test case which is closer to the real world and I indeed was able to reproduce this. Whether this is actually a bug in Chrome or Firefox is an entirely different issue and even IF it is the fault of the browsers and it is fixed at some point, we'd still need to handle this for older browser versions. Apart from clearing the header, I also recreated the patch by using a plain "git diff" with a small description on top. This should make it easier for future authors to work on that patch. [1]: https://github.com/NixOS/nixpkgs/pull/48337#issuecomment-495072764 [2]: https://github.com/NixOS/nixpkgs/pull/48337#issuecomment-451644084 [3]: https://github.com/NixOS/nixpkgs/pull/48337#issuecomment-451646135 Signed-off-by: aszlig <aszlig@nix.build>
2019-12-30 14:06:00 +01:00
nginx-etag = handleTest ./nginx-etag.nix {};
nginx: Fix ETag patch to ignore realpath(3) error While our ETag patch works pretty fine if it comes to serving data off store paths, it unfortunately broke something that might be a bit more common, namely when using regexes to extract path components of location directives for example. Recently, @devhell has reported a bug with a nginx location directive like this: location ~^/\~([a-z0-9_]+)(/.*)?$" { alias /home/$1/public_html$2; } While this might look harmless at first glance, it does however cause issues with our ETag patch. The alias directive gets broken up by nginx like this: *2 http script copy: "/home/" *2 http script capture: "foo" *2 http script copy: "/public_html/" *2 http script capture: "bar.txt" In our patch however, we use realpath(3) to get the canonicalised path from ngx_http_core_loc_conf_s.root, which returns the *configured* value from the root or alias directive. So in the example above, realpath(3) boils down to the following syscalls: lstat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat("/home/$1", 0x7ffd08da6f60) = -1 ENOENT (No such file or directory) During my review[1] of the initial patch, I didn't actually notice that what we're doing here is returning NGX_ERROR if the realpath(3) call fails, which in turn causes an HTTP 500 error. Since our patch actually made the canonicalisation (and thus additional syscalls) necessary, we really shouldn't introduce an additional error so let's - at least for now - silently skip return value if realpath(3) has failed. However since we're using the unaltered root from the config we have another issue, consider this root: /nix/store/...-abcde/$1 Calling realpath(3) on this path will fail (except if there's a file called "$1" of course), so even this fix is not enough because it results in the ETag not being set to the store path hash. While this is very ugly and we should fix this very soon, it's not as serious as getting HTTP 500 errors for serving static files. I added a small NixOS VM test, which uses the example above as a regression test. It seems that my memory is failing these days, since apparently I *knew* about this issue since digging for existing issues in nixpkgs, I found this similar pull request which I even reviewed: https://github.com/NixOS/nixpkgs/pull/66532 However, since the comments weren't addressed and the author hasn't responded to the pull request, I decided to keep this very commit and do a follow-up pull request. [1]: https://github.com/NixOS/nixpkgs/pull/48337 Signed-off-by: aszlig <aszlig@nix.build> Reported-by: @devhell Acked-by: @7c6f434c Acked-by: @yorickvP Merges: https://github.com/NixOS/nixpkgs/pull/80671 Fixes: https://github.com/NixOS/nixpkgs/pull/66532
2020-02-20 20:43:42 +01:00
nginx-pubhtml = handleTest ./nginx-pubhtml.nix {};
nixos/tests: add nginx-sandbox test
2020-04-23 21:00:27 +02:00
nginx-sandbox = handleTestOn ["x86_64-linux"] ./nginx-sandbox.nix {};
nixos/tests: add nginx-sso basic functionality test
2018-12-28 11:41:52 +01:00
nginx-sso = handleTest ./nginx-sso.nix {};
nixos/nginx: ensure all variants have a basic level of testing
2020-06-02 07:01:03 +02:00
nginx-variants = handleTest ./nginx-variants.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
nix-ssh-serve = handleTest ./nix-ssh-serve.nix {};
nixos-generate-config: enable overriding configuration.nix
2019-08-07 18:04:18 +02:00
nixos-generate-config = handleTest ./nixos-generate-config.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
novacomd = handleTestOn ["x86_64-linux"] ./novacomd.nix {};
nsd = handleTest ./nsd.nix {};
nixos/nzbget: fix broken service, add a nixos test, as well as some general improvements
2019-04-22 14:06:33 +02:00
nzbget = handleTest ./nzbget.nix {};
oh-my-zsh: Add test
2020-11-05 02:37:50 +01:00
oh-my-zsh = handleTest ./oh-my-zsh.nix {};
openarena: add test
2019-10-22 16:20:56 +02:00
openarena = handleTest ./openarena.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
openldap = handleTest ./openldap.nix {};
opensmtpd = handleTest ./opensmtpd.nix {};
openssh = handleTest ./openssh.nix {};
Rename `novaImage` to `openstackImage` People don't necessary know `nova` is related to Openstack (it is a component of Openstack). So, it is more explicit to call it `openstackImage`.
2019-01-28 15:09:48 +01:00
openstack-image-metadata = (handleTestOn ["x86_64-linux"] ./openstack-image.nix {}).metadata or {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
openstack-image-userdata = (handleTestOn ["x86_64-linux"] ./openstack-image.nix {}).userdata or {};
nixosTests.image-contents: init
2020-12-20 21:18:54 +01:00
image-contents = handleTest ./image-contents.nix {};
nixos/orangefs: add test
2019-08-21 00:27:14 +02:00
orangefs = handleTest ./orangefs.nix {};
mention the os-prober test in pkgs.os-prober.passthru.tests
2019-06-09 20:26:05 +02:00
os-prober = handleTestOn ["x86_64-linux"] ./os-prober.nix {};
nixos/tests: add osrm-backend test
2019-01-05 13:13:10 +01:00
osrm-backend = handleTest ./osrm-backend.nix {};
nixos/overlayfs: add test
2019-01-23 10:19:23 +01:00
overlayfs = handleTest ./overlayfs.nix {};
nixos/packagekit: add test
2019-04-24 10:45:29 +02:00
packagekit = handleTest ./packagekit.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
pam-oath-login = handleTest ./pam-oath-login.nix {};
nixos/pam: refactor U2F, docs about u2f_keys path (#54756) * change enableU2F option to u2f.* set * add few u2f options (not all) to customize pam-u2f module * document default u2f_keys locations Co-authored-by: Tomasz Czyż <tomasz.czyz@gmail.com> Co-authored-by: Arda Xi <arda@ardaxi.com>
2019-01-29 17:45:26 +01:00
pam-u2f = handleTest ./pam-u2f.nix {};
nixos/tests/all-tests.nix: add pantheon
2019-01-24 23:33:05 +01:00
pantheon = handleTest ./pantheon.nix {};
paperless service: init
2019-01-27 15:26:31 +01:00
paperless = handleTest ./paperless.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
pdns-recursor = handleTest ./pdns-recursor.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
peerflix = handleTest ./peerflix.nix {};
pgjwt = handleTest ./pgjwt.nix {};
pgmanage = handleTest ./pgmanage.nix {};
nixos/php: Add tests for phpfpm This test checks that we evaluate PHP properly and that certain extensions are actually loaded.
2020-03-30 22:07:05 +02:00
php = handleTest ./php {};
nixos/tests/pinnwand: init
2020-06-03 23:12:06 +02:00
pinnwand = handleTest ./pinnwand.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
plasma5 = handleTest ./plasma5.nix {};
plotinus = handleTest ./plotinus.nix {};
nixos/podman: restrict test to x86_64-linux
2020-07-02 16:17:15 +02:00
podman = handleTestOn ["x86_64-linux"] ./podman.nix {};
postfix: Add submissions option for postfix and test (#91691) RFC 8314 suggests, for end user submission of mails, SMTP over TLS on port 465 should be used. Closes #91690
2020-07-06 03:37:56 +02:00
postfix = handleTest ./postfix.nix {};
postfix-raise-smtpd-tls-security-level = handleTest ./postfix-raise-smtpd-tls-security-level.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
postgis = handleTest ./postgis.nix {};
postgresql = handleTest ./postgresql.nix {};
nixos/postgresql-wal-receiver: add module (#63799)
2019-08-11 19:09:42 +02:00
postgresql-wal-receiver = handleTest ./postgresql-wal-receiver.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
powerdns = handleTest ./powerdns.nix {};
nixos/tests/pppd: init This test creates a PPPoE link between two machines, and verifies that the machines can ping each other.
2019-10-15 06:26:54 +02:00
pppd = handleTest ./pppd.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
predictable-interface-names = handleTest ./predictable-interface-names.nix {};
printing = handleTest ./printing.nix {};
privacyidea module: init
2020-04-21 13:37:00 +02:00
privacyidea = handleTest ./privacyidea.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
prometheus = handleTest ./prometheus.nix {};
prometheus-exporters = handleTest ./prometheus-exporters.nix {};
nixos/tests: move ejabberd and prosody test to xmpp folder
2019-06-15 11:16:28 +02:00
prosody = handleTest ./xmpp/prosody.nix {};
nixos/tests/prosodyMysql: add check work prosody with MySQL database
2019-06-15 11:58:00 +02:00
prosodyMysql = handleTest ./xmpp/prosody-mysql.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
proxy = handleTest ./proxy.nix {};
pt2-clone: add nixos test
2020-07-29 19:00:33 +02:00
pt2-clone = handleTest ./pt2-clone.nix {};
nixos/qemu-vm: add option to use a non-standard BIOS I'd like to change the default on x86 platforms to qboot at some point, since it saves a fair bit of startup time.
2020-05-22 05:15:32 +02:00
qboot = handleTestOn ["x86_64-linux" "i686-linux"] ./qboot.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
quagga = handleTest ./quagga.nix {};
nixos/quorum: init
2020-03-22 17:26:55 +01:00
quorum = handleTest ./quorum.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
rabbitmq = handleTest ./rabbitmq.nix {};
nixos/radarr: Add test for radarr to ensure startup
2019-01-24 23:09:21 +01:00
radarr = handleTest ./radarr.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
radicale = handleTest ./radicale.nix {};
nixos/redis: add test
2019-08-31 20:17:33 +02:00
redis = handleTest ./redis.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
redmine = handleTest ./redmine.nix {};
nixos/tests/restic.nix: add test
2020-01-30 22:31:52 +01:00
restic = handleTest ./restic.nix {};
ripgrep: Add test
2020-12-23 18:30:39 +01:00
ripgrep = handleTest ./ripgrep.nix {};
nixos/tests/robustirc-bridge: init
2020-08-30 18:31:54 +02:00
robustirc-bridge = handleTest ./robustirc-bridge.nix {};
roundcube: apply code review suggestions
2018-11-28 17:33:26 +01:00
roundcube = handleTest ./roundcube.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
rspamd = handleTest ./rspamd.nix {};
rss2email module: init Also adding `system-sendmail` package for sharing the code with other modules or packages needing it.
2018-10-27 11:33:43 +02:00
rss2email = handleTest ./rss2email.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
rsyslogd = handleTest ./rsyslogd.nix {};
runInMachine = handleTest ./run-in-machine.nix {};
rxe = handleTest ./rxe.nix {};
samba = handleTest ./samba.nix {};
nixos/tests/samba-wsdd: add check WSD Discovery
2020-11-23 15:13:22 +01:00
samba-wsdd = handleTest ./samba-wsdd.nix {};
nixos/sanoid, nixos/syncoid: init module and test
2019-10-27 04:37:30 +01:00
sanoid = handleTest ./sanoid.nix {};
sbt: Add test
2020-11-03 17:51:36 +01:00
sbt = handleTest ./sbt.nix {};
sbt-extras: Add test
2020-11-11 15:31:57 +01:00
sbt-extras = handleTest ./sbt-extras.nix {};
scala: Refactor, add tests Abstract over Scala derivation, add tests for individual versions
2020-11-05 14:32:28 +01:00
scala = handleTest ./scala.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
sddm = handleTest ./sddm.nix {};
nixos/service-runner.nix: Allow quotes in commands + test
2020-02-28 12:17:01 +01:00
service-runner = handleTest ./service-runner.nix {};
nixos/shadowsocks: add test without plugin
2020-09-09 00:15:59 +02:00
shadowsocks = handleTest ./shadowsocks {};
shattered-pixel-dungeon: add nixos test
2020-08-09 15:20:17 +02:00
shattered-pixel-dungeon = handleTest ./shattered-pixel-dungeon.nix {};
nixos/tests: add shiori to all-tests.nix
2019-11-08 18:17:08 +01:00
shiori = handleTest ./shiori.nix {};
nixosTests.signal-desktop: add test
2019-05-23 00:50:51 +02:00
signal-desktop = handleTest ./signal-desktop.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
simple = handleTest ./simple.nix {};
slurm = handleTest ./slurm.nix {};
smokeping = handleTest ./smokeping.nix {};
nixos/tests: add snapcast Checks - if all configured ports are listened on - if all pipes for multiple streams get set up - if rpc interaction is possible
2020-07-28 14:47:36 +02:00
snapcast = handleTest ./snapcast.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
snapper = handleTest ./snapper.nix {};
nixosTests.sogo: init test
2020-05-12 18:32:39 +02:00
sogo = handleTest ./sogo.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
solr = handleTest ./solr.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
sonarr = handleTest ./sonarr.nix {};
nixos/spacecookie: add service module and test
2019-05-24 21:17:51 +02:00
spacecookie = handleTest ./spacecookie.nix {};
spike: add test to nixosTests
2020-04-22 14:40:38 +02:00
spike = handleTest ./spike.nix {};
nixos: add test for sslh
2020-01-18 13:00:00 +01:00
sslh = handleTest ./sslh.nix {};
nixos/sssd: fix the module 'system.nssModules' was not set correctly fix #91242
2020-08-24 15:55:22 +02:00
sssd = handleTestOn ["x86_64-linux"] ./sssd.nix {};
nixos/tests/sssd-ldap: init
2020-09-01 07:03:20 +02:00
sssd-ldap = handleTestOn ["x86_64-linux"] ./sssd-ldap.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
strongswan-swanctl = handleTest ./strongswan-swanctl.nix {};
sudo = handleTest ./sudo.nix {};
switchTest = handleTest ./switch-test.nix {};
nixos/sympa: init module
2019-07-06 20:56:30 +02:00
sympa = handleTest ./sympa.nix {};
nixos/tests: Add test for syncthing
2020-07-23 09:13:26 +02:00
syncthing = handleTest ./syncthing.nix {};
nixos/syncthing: add options for declarative device/folder config
2019-04-21 23:05:07 +02:00
syncthing-init = handleTest ./syncthing-init.nix {};
syncthing-relay module: init
2018-11-17 15:02:00 +01:00
syncthing-relay = handleTest ./syncthing-relay.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
systemd = handleTest ./systemd.nix {};
nixos/tests: add systemd-analyze test
2019-11-25 00:03:55 +01:00
systemd-analyze = handleTest ./systemd-analyze.nix {};
nixosTests.systemd-binfmt: init This adds a simple test running GNU Hello cross-compiled for armv7l and aarch64 inside a x86_64 VM with configured binfmt. We already build the cross toolchains in other invocations, and building hello itself is small.
2020-05-18 11:16:56 +02:00
systemd-binfmt = handleTestOn ["x86_64-linux"] ./systemd-binfmt.nix {};
nixos/systemd-boot: run test on aarch64
2020-06-14 05:57:52 +02:00
systemd-boot = handleTest ./systemd-boot.nix {};
nixos/systemd-chroot: Rename chroot to confinement Quoting @edolstra from [1]: I don't really like the name "chroot", something like "confine[ment]" or "restrict" seems better. Conceptually we're not providing a completely different filesystem tree but a restricted view of the same tree. I already used "confinement" as a sub-option and I do agree that "chroot" sounds a bit too specific (especially because not *only* chroot is involved). So this changes the module name and its option to use "confinement" instead of "chroot" and also renames the "chroot.confinement" to "confinement.mode". [1]: https://github.com/NixOS/nixpkgs/pull/57519#issuecomment-472855704 Signed-off-by: aszlig <aszlig@nix.build>
2019-03-14 15:26:10 +01:00
systemd-confinement = handleTest ./systemd-confinement.nix {};
nixos.tests.systemd-journal: add basic systemd-journal-gatewayd test This test allows to ensure the systemd-journal-gatewayd service is responding correcly when the NixOS option `enableHttpGateway` is set. The test has not been added into the main systemd test because a graphical stack is not required (and rebuilding the graphical stack on systemd change is huge).
2020-11-01 18:48:40 +01:00
systemd-journal = handleTest ./systemd-journal.nix {};
nixos/networkd: test routingPolicyRules with a nixos vm test
2020-02-29 19:34:48 +01:00
systemd-networkd = handleTest ./systemd-networkd.nix {};
systemd-networkd: add DHCPServer test
2019-11-16 12:13:51 +01:00
systemd-networkd-dhcpserver = handleTest ./systemd-networkd-dhcpserver.nix {};
nixos/tests: add systemd-networkd-ipv6-prefix-delegation This is a follow-up to the PR #82026 that contains the promised tests. In this test I am testing if we can properly propagate prefixes received via DHCPv6 PD with the networkd options in our module system. The comments in the test should be sufficient to follow the idea and what is going on.
2020-05-01 15:12:19 +02:00
systemd-networkd-ipv6-prefix-delegation = handleTest ./systemd-networkd-ipv6-prefix-delegation.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
systemd-networkd-vrf = handleTest ./systemd-networkd-vrf.nix {};
nixosTests.systemd-nspawn: add test This adds a test downloading an nspawn container via http, and ensures sha256sum verification and gpg signature verification work.
2019-11-02 19:55:41 +01:00
systemd-nspawn = handleTest ./systemd-nspawn.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
systemd-timesyncd = handleTest ./systemd-timesyncd.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
taskserver = handleTest ./taskserver.nix {};
nixos/telegraf: add test
2019-01-21 12:30:11 +01:00
telegraf = handleTest ./telegraf.nix {};
nixos/tiddlywiki: init Service that runs TiddlyWiki nodejs server
2019-04-29 22:46:00 +02:00
tiddlywiki = handleTest ./tiddlywiki.nix {};
nixos/tests/timezone: port to python
2019-12-02 23:28:53 +01:00
timezone = handleTest ./timezone.nix {};
nixos/tests/tinc: init with simple test
2020-12-06 16:05:21 +01:00
tinc = handleTest ./tinc {};
nixos: add test for tinydns
2019-05-16 23:42:02 +02:00
tinydns = handleTest ./tinydns.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
tor = handleTest ./tor.nix {};
nixos/traefik: add test
2020-04-06 08:21:35 +02:00
# traefik test relies on docker-containers
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
trac = handleTest ./trac.nix {};
nixos/traefik: add test
2020-04-06 08:21:35 +02:00
traefik = handleTestOn ["x86_64-linux"] ./traefik.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
transmission = handleTest ./transmission.nix {};
tests: adding trezord
2019-08-16 17:00:07 +02:00
trezord = handleTest ./trezord.nix {};
nixos/trickster: add test
2019-11-01 11:03:23 +01:00
trickster = handleTest ./trickster.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
trilium-server = handleTestOn ["x86_64-linux"] ./trilium-server.nix {};
nixosTests.tuptime: init test
2020-03-24 23:45:49 +01:00
tuptime = handleTest ./tuptime.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
ucg = handleTest ./ucg.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
udisks2 = handleTest ./udisks2.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
unbound = handleTest ./unbound.nix {};
nixos/tests: add unit-php test
2020-04-16 22:08:00 +02:00
unit-php = handleTest ./web-servers/unit-php.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
upnp = handleTest ./upnp.nix {};
nixos: add test for uwsgi
2019-05-27 23:03:22 +02:00
uwsgi = handleTest ./uwsgi.nix {};
nixos/tests/v2ray: init
2020-06-12 10:12:51 +02:00
v2ray = handleTest ./v2ray.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
vault = handleTest ./vault.nix {};
nixos/vector: add module
2020-11-30 08:22:08 +01:00
vector = handleTest ./vector.nix {};
victoriametrics: add module, tests
2020-01-19 18:55:56 +01:00
victoriametrics = handleTest ./victoriametrics.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
virtualbox = handleTestOn ["x86_64-linux"] ./virtualbox.nix {};
tests/wasabibackend: init
2020-06-18 14:19:13 +02:00
wasabibackend = handleTest ./wasabibackend.nix {};
nixos/wireguard: add test After working on the last wireguard bump (#57534), we figured that it's probably a good idea to have a basic test which confirms that a simple VPN with wireguard still works. This test starts two peers with a `wg0` network interface and adds a v4 and a v6 route that goes through `wg0`.
2019-03-17 13:20:38 +01:00
wireguard = handleTest ./wireguard {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
wordpress = handleTest ./wordpress.nix {};
nixosTests.xandikos: init
2019-12-14 01:17:49 +01:00
xandikos = handleTest ./xandikos.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
xautolock = handleTest ./xautolock.nix {};
xfce = handleTest ./xfce.nix {};
xmonad = handleTest ./xmonad.nix {};
xrdp = handleTest ./xrdp.nix {};
xss-lock = handleTest ./xss-lock.nix {};
xterm: Add test
2020-11-17 04:13:13 +01:00
xterm = handleTest ./xterm.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
yabar = handleTest ./yabar.nix {};
nixos/yggdrasil: add service
2019-06-27 17:56:10 +02:00
yggdrasil = handleTest ./yggdrasil.nix {};
yq: Add test
2020-12-18 18:07:30 +01:00
yq = handleTest ./yq.nix {};
nixosTests.zfs: Add to all-tests.nix
2020-02-03 18:33:26 +01:00
zfs = handleTest ./zfs.nix {};
nixos/zigbee2mqtt: add test to all-tests.nix
2020-08-03 12:43:13 +02:00
zigbee2mqtt = handleTest ./zigbee2mqtt.nix {};
nixos/zoneminder: add minimal test
2020-04-11 19:28:52 +02:00
zoneminder = handleTest ./zoneminder.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
zookeeper = handleTest ./zookeeper.nix {};
nixos/zoneminder: add minimal test
2020-04-11 19:28:52 +02:00
zsh-history = handleTest ./zsh-history.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
}
Reference in a new issue Copy permalink