JakeHillion/nixpkgs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
a432f832bf
nixpkgs/nixos/tests/all-tests.nix

351 lines
17 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 11:30:07 +00: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 13:55:23 +00: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 11:30:07 +00: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 12:56:05 +01: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 22:12:15 +00:00
acme = handleTest ./acme.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 11:30:07 +00:00
atd = handleTest ./atd.nix {};
avahi = handleTest ./avahi.nix {};
nixos/tests: add babeld
2019-10-12 00:30:55 +01:00
babeld = handleTest ./babeld.nix {};
tests: disable some broken tests and/or restrict to x86_64
2018-11-11 12:27:58 +00: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 13:10:02 +00:00
beanstalkd = handleTest ./beanstalkd.nix {};
nixosTests.bees: port to python
2019-11-24 00:10:17 +00: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 11:30:07 +00:00
bind = handleTest ./bind.nix {};
bittorrent = handleTest ./bittorrent.nix {};
nixos/buildkite-agents: support multiple buildkite agents
2020-01-23 16:19:53 +00:00
buildkite-agents = handleTest ./buildkite-agents.nix {};
tests: disable some broken tests and/or restrict to x86_64
2018-11-11 12:27:58 +00: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 11:30:07 +00:00
boot-stage1 = handleTest ./boot-stage1.nix {};
borgbackup = handleTest ./borgbackup.nix {};
buildbot = handleTest ./buildbot.nix {};
nixos/caddy: add tests (#70778)
2019-10-09 12:32:03 +01: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 11:30:07 +00: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 19:43:48 +00:00
cage = handleTest ./cage.nix {};
nixos/cassandra: Reenable tests
2019-04-22 17:06:40 +01:00
cassandra = handleTest ./cassandra.nix {};
nixos/ceph: Rename old ceph test and add new multi-node test to all-tests.nix
2019-11-01 12:12:18 +00:00
ceph-single-node = handleTestOn ["x86_64-linux"] ./ceph-single-node.nix {};
ceph-multi-node = handleTestOn ["x86_64-linux"] ./ceph-multi-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 11:30:07 +00:00
certmgr = handleTest ./certmgr.nix {};
cfssl = handleTestOn ["x86_64-linux"] ./cfssl.nix {};
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 14:06:53 +00: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 11:30:07 +00:00
cloud-init = handleTest ./cloud-init.nix {};
codimd = handleTest ./codimd.nix {};
nixos/consul: register test
2019-11-24 14:08:53 +00:00
consul = handleTest ./consul.nix {};
nixosTests.cockroachdb: add to all-tests.nix
2019-11-22 20:49:16 +00:00
cockroachdb = handleTestOn ["x86_64-linux"] ./cockroachdb.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 11:30:07 +00:00
containers-bridge = handleTest ./containers-bridge.nix {};
nixos-containers: Add support for custom nixpkgs argument
2020-04-19 14:41:18 +01:00
containers-custom-pkgs.nix = handleTest ./containers-custom-pkgs.nix {};
nixos/containers: add 'ephemeral' option
2019-08-18 20:37:38 +01: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 11:30:07 +00: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-25 23:44:12 +00: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 11:30:07 +00: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 19:34:37 +00:00
containers-portforward = handleTest ./containers-portforward.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 11:30:07 +00:00
containers-restart_networking = handleTest ./containers-restart_networking.nix {};
containers-tmpfs = handleTest ./containers-tmpfs.nix {};
nixos/corerad: init
2020-01-07 16:52:32 +00:00
corerad = handleTest ./corerad.nix {};
nixos/tests: Reenable couchdb Works just fine in current master
2019-07-24 19:48:43 +01:00
couchdb = handleTest ./couchdb.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 11:30:07 +00:00
deluge = handleTest ./deluge.nix {};
dhparams = handleTest ./dhparams.nix {};
nixosTests.dnscrypt-proxy2: init This removes the old dnscrypt-proxy test.
2020-02-01 23:59:02 +00:00
dnscrypt-proxy2 = handleTestOn ["x86_64-linux"] ./dnscrypt-proxy2.nix {};
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 04:13:36 +01: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 11:30:07 +00:00
docker = handleTestOn ["x86_64-linux"] ./docker.nix {};
nixos/docker-containers: Rename to virtualisation.oci-containers.containers. And allow the runtime to be configurable via the `virtualisation.oci-containers.backend` option. Valid choices are "podman" and "docker".
2020-04-20 12:31:07 +01:00
oci-containers = handleTestOn ["x86_64-linux"] ./oci-containers.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 11:30:07 +00:00
docker-edge = handleTestOn ["x86_64-linux"] ./docker-edge.nix {};
docker-preloader = handleTestOn ["x86_64-linux"] ./docker-preloader.nix {};
docker-registry = handleTest ./docker-registry.nix {};
docker-tools = handleTestOn ["x86_64-linux"] ./docker-tools.nix {};
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 18:04:28 +00:00
documize = handleTest ./documize.nix {};
nixos/dokuwiki: init module at 2018-04-22b
2019-12-25 22:04:55 +00: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 11:30:07 +00:00
dovecot = handleTest ./dovecot.nix {};
# ec2-config doesn't work in a sandbox as the simulated ec2 instance needs network access
#ec2-config = (handleTestOn ["x86_64-linux"] ./ec2.nix {}).boot-ec2-config or {};
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 10:16:28 +01: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 11:30:07 +00:00
elk = handleTestOn ["x86_64-linux"] ./elk.nix {};
nixos/tests: add enlightenment desktop environment
2020-05-02 15:28:50 +01: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 11:30:07 +00:00
env = handleTest ./env.nix {};
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 00:46:21 +01:00
etcd-cluster = handleTestOn ["x86_64-linux"] ./etcd-cluster.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 14:06:32 +00:00
fancontrol = handleTest ./fancontrol.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 11:30:07 +00: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 17:01:47 +00:00
firefox-esr = handleTest ./firefox.nix { esr = 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 11:30:07 +00:00
firewall = handleTest ./firewall.nix {};
nixos/fish: generate autocompletions from man pages
2018-12-17 19:12:09 +00:00
fish = handleTest ./fish.nix {};
nixos/flannel: fix flannel nixos test, add test to all-tests.nix
2019-02-12 17:26:08 +00:00
flannel = handleTestOn ["x86_64-linux"] ./flannel.nix {};
fluentd: add simple test
2019-07-29 16:35:27 +01:00
fluentd = handleTest ./fluentd.nix {};
nixos.tests.fontconfig-default-fonts: init Make sure the fonts.enableDefaultFonts option works.
2019-08-29 13:02:20 +01:00
fontconfig-default-fonts = handleTest ./fontconfig-default-fonts.nix {};
nixos/freeswitch: init
2020-01-07 14:53:34 +00: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 11:30:07 +00:00
fsck = handleTest ./fsck.nix {};
nixos: add gerrit module Co-authored-by: edef <edef@edef.eu> Co-authored-by: Florian Klink <flokli@flokli.de>
2020-03-05 21:11:28 +00:00
gerrit = handleTest ./gerrit.nix {};
nixos/gotify: init module and test
2019-10-25 14:14:57 +01:00
gotify-server = handleTest ./gotify-server.nix {};
nixos/grocy: init module Co-authored-by: elseym <elseym@me.com>
2020-02-07 22:30:40 +00:00
grocy = handleTest ./grocy.nix {};
nixos/git-daemon: only create git user if it will be used
2020-02-26 13:05:00 +00: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 11:30:07 +00: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-04 23:10:57 +00:00
gitolite-fcgiwrap = handleTest ./gitolite-fcgiwrap.nix {};
nixos/glusterfs: add test
2019-08-17 00:28:43 +01:00
glusterfs = handleTest ./glusterfs.nix {};
nixosTests.gnome{xorg}: re-enable on aarch64
2019-08-07 03:01:17 +01:00
gnome3-xorg = handleTest ./gnome3-xorg.nix {};
gnome3 = handleTest ./gnome3.nix {};
nixos/tests: add gnome-installed-tests with builder function The test script is also ported to python.
2019-11-06 00:56:21 +00:00
installed-tests = pkgs.recurseIntoAttrs (handleTest ./installed-tests {});
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 11:30:07 +00:00
gocd-agent = handleTest ./gocd-agent.nix {};
gocd-server = handleTest ./gocd-server.nix {};
nixosTests.graphene: init
2019-05-17 02:29:17 +01:00
google-oslogin = handleTest ./google-oslogin {};
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 11:30:07 +00: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 01:01:43 +01:00
graylog = handleTest ./graylog.nix {};
nixosTests.gvisor: add test for gvisor and gvisor as a Docker runtime
2019-11-27 07:01:46 +00: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 11:30:07 +00: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 06:45:00 +00: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 11:30:07 +00:00
haproxy = handleTest ./haproxy.nix {};
nixos/tests: re-enable hardened test Has been okay since 62623b60d5fed91ac676d6f4a70a12570090d513
2019-01-06 13:04:41 +00:00
hardened = handleTest ./hardened.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 13:33:57 +00: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 11:30:07 +00:00
hitch = handleTest ./hitch {};
hocker-fetchdocker = handleTest ./hocker-fetchdocker {};
home-assistant = handleTest ./home-assistant.nix {};
hound = handleTest ./hound.nix {};
hydra = handleTest ./hydra {};
hydra: 2020-02-06 -> 2020-03-{24,27} Upgrades Hydra to the latest master/flake branch. To perform this upgrade, it's needed to do a non-trivial db-migration which provides a massive performance-improvement[1]. The basic ideas behind multi-step upgrades of services between NixOS versions have been gathered already[2]. For further context it's recommended to read this first. Basically, the following steps are needed: * Upgrade to a non-breaking version of Hydra with the db-changes (columns are still nullable here). If `system.stateVersion` is set to something older than 20.03, the package will be selected automatically, otherwise `pkgs.hydra-migration` needs to be used. * Run `hydra-backfill-ids` on the server. * Deploy either `pkgs.hydra-unstable` (for Hydra master) or `pkgs.hydra-flakes` (for flakes-support) to activate the optimization. The steps are also documented in the release-notes and in the module using `warnings`. `pkgs.hydra` has been removed as latest Hydra doesn't compile with `pkgs.nixStable` and to ensure a graceful migration using the newly introduced packages. To verify the approach, a simple vm-test has been added which verifies the migration steps. [1] https://github.com/NixOS/hydra/pull/711 [2] https://github.com/NixOS/nixpkgs/pull/82353#issuecomment-598269471
2020-03-27 21:09:13 +00:00
hydra-db-migration = handleTest ./hydra/db-migration.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 11:30:07 +00:00
i3wm = handleTest ./i3wm.nix {};
nixos/icingaweb: Fix module path; Add test
2019-07-07 02:03:59 +01: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 11:30:07 +00:00
iftop = handleTest ./iftop.nix {};
ihatemoney: init at 4.1 plus module and test
2019-09-16 16:08:32 +01:00
ihatemoney = handleTest ./ihatemoney.nix {};
nixos/tests/all-tests.nix: Fix incron test path
2018-11-14 22:51:15 +00: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 11:30:07 +00:00
influxdb = handleTest ./influxdb.nix {};
initrd-network-ssh = handleTest ./initrd-network-ssh {};
initrdNetwork = handleTest ./initrd-network.nix {};
installer = handleTest ./installer.nix {};
nixos/iodine: add test
2020-02-02 12:00:00 +00:00
iodine = handleTest ./iodine.nix {};
nixos/ipfs: convert tests to python driver & simplify
2020-05-08 10:48:47 +01: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 11:30:07 +00:00
ipv6 = handleTest ./ipv6.nix {};
nixos/jackett: Add test for jackett to ensure startup
2019-01-25 06:09:36 +00:00
jackett = handleTest ./jackett.nix {};
nixos/jellyfin: add test to all-tests.nix
2019-05-01 10:57:34 +01: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 11:30:07 +00:00
jenkins = handleTest ./jenkins.nix {};
nixos/jirefeau: add `services.jirafeau` module Signed-off-by: David Wood <david.wood@codeplay.com>
2020-02-06 16:00:19 +00:00
jirafeau = handleTest ./jirafeau.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 15:39:54 +01: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 13:39:25 +01:00
kafka = handleTest ./kafka.nix {};
nixos/keepalived: add test
2019-12-22 07:45:31 +00:00
keepalived = handleTest ./keepalived.nix {};
nixos/tests/kerberos: fix evaluation
2019-01-11 04:36:51 +00: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 11:30:07 +00:00
kernel-latest = handleTest ./kernel-latest.nix {};
kernel-lts = handleTest ./kernel-lts.nix {};
linux: Add testing test
2019-04-01 13:31:36 +01:00
kernel-testing = handleTest ./kernel-testing.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 11:30:07 +00:00
keymap = handleTest ./keymap.nix {};
nixos/knot: init
2019-03-13 00:12:56 +00:00
knot = handleTest ./knot.nix {};
nixosTests.krb5: Add to all-tests.nix
2020-02-14 08:56:43 +00: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 11:30:07 +00: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 00:29:24 +01: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 11:30:07 +00:00
latestKernel.login = handleTest ./login.nix { latestKernel = true; };
leaps = handleTest ./leaps.nix {};
nixos/lidarr: Add test for lidarr to ensure startup
2019-01-24 22:09:42 +00: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-06 23:29:50 +01:00
lightdm = handleTest ./lightdm.nix {};
nixos/limesurvey: add basic nixos test
2019-03-16 12:24:23 +00:00
limesurvey = handleTest ./limesurvey.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 11:30:07 +00:00
login = handleTest ./login.nix {};
nixos/tests: add test for loki
2019-06-27 17:11:09 +01:00
loki = handleTest ./loki.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 11:30:07 +00: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 10:57:05 +00:00
lorri = handleTest ./lorri/default.nix {};
nixos/tests/magnetico: port to python
2019-11-13 18:17:32 +00:00
magnetico = handleTest ./magnetico.nix {};
nixos/tests: add magic-wormhole-mailbox-server
2020-03-30 12:30:05 +01:00
magic-wormhole-mailbox-server = handleTest ./magic-wormhole-mailbox-server.nix {};
nixos/mailcatcher: add nixos test
2019-03-27 11:35:24 +00:00
mailcatcher = handleTest ./mailcatcher.nix {};
nixos/tests: add check mariadb galera cluster with mariabackup-based SST
2020-04-05 19:39:35 +01:00
mariadb-galera-mariabackup = handleTest ./mysql/mariadb-galera-mariabackup.nix {};
nixos/tests: add check mariadb galera cluster with rsync-based SST
2020-04-05 19:58:27 +01:00
mariadb-galera-rsync = handleTest ./mysql/mariadb-galera-rsync.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 11:30:07 +00:00
mathics = handleTest ./mathics.nix {};
nixos/matomo: add test
2019-10-04 21:38:58 +01: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 11:30:07 +00:00
matrix-synapse = handleTest ./matrix-synapse.nix {};
nixos/mediawiki: init service to replace httpd subservice
2019-06-06 02:19:11 +01: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 11:30:07 +00:00
memcached = handleTest ./memcached.nix {};
mesos = handleTest ./mesos.nix {};
tests: adding metabase service test
2019-08-18 08:28:16 +01:00
metabase = handleTest ./metabase.nix {};
miniflux: add service
2018-12-21 18:36:58 +00:00
miniflux = handleTest ./miniflux.nix {};
minio: add test to nixos/tests/all-tests.nix
2019-02-05 16:38:34 +00:00
minio = handleTest ./minio.nix {};
nixos/minidlna: Allow more configuration options This commits allows the user to configure: - more minidlna options - the ones not yet disclosed in nix (extending the existing minimal subset)
2019-03-07 10:29:25 +00:00
minidlna = handleTest ./minidlna.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 11:30:07 +00:00
misc = handleTest ./misc.nix {};
nixos/moin: init
2019-07-16 00:06:19 +01: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 11:30:07 +00:00
mongodb = handleTest ./mongodb.nix {};
nixos/moodle: init service
2019-06-21 15:09:15 +01: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 11:30:07 +00:00
morty = handleTest ./morty.nix {};
nixos/mosquitto: add test
2019-04-24 09:23:13 +01: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 11:30:07 +00: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 21:18:01 +01:00
mxisd = handleTest ./mxisd.nix {};
nixos/tests: move mysql tests to subfolder
2020-04-02 21:40:55 +01: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 {};
nagios: add nixos test
2019-12-30 12:00:00 +00:00
nagios = handleTest ./nagios.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 11:30:07 +00: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/ndppd: register test
2019-02-03 15:47:01 +00:00
ndppd = handleTest ./ndppd.nix {};
neo4j: add neo4j test
2019-02-01 13:29:54 +00:00
neo4j = handleTest ./neo4j.nix {};
specialisation: replace nesting with named configurations Co-authored-by: worldofpeace <worldofpeace@protonmail.ch>
2020-03-05 22:07:20 +00: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 11:30:07 +00:00
netdata = handleTest ./netdata.nix {};
networking.networkd = handleTest ./networking.nix { networkd = true; };
networking.scripted = handleTest ./networking.nix { networkd = false; };
# 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 14:37:27 +00: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 11:30:07 +00:00
nghttpx = handleTest ./nghttpx.nix {};
nginx = handleTest ./nginx.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 13:06:00 +00: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 19:43:42 +00:00
nginx-pubhtml = handleTest ./nginx-pubhtml.nix {};
nixos/tests: add nginx-sso basic functionality test
2018-12-28 10:41:52 +00:00
nginx-sso = handleTest ./nginx-sso.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 11:30:07 +00:00
nix-ssh-serve = handleTest ./nix-ssh-serve.nix {};
nixos-generate-config: enable overriding configuration.nix
2019-08-07 17:04:18 +01: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 11:30:07 +00: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 13:06:33 +01:00
nzbget = handleTest ./nzbget.nix {};
openarena: add test
2019-10-22 15:20:56 +01: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 11:30:07 +00:00
openldap = handleTest ./openldap.nix {};
opensmtpd = handleTest ./opensmtpd.nix {};
openssh = handleTest ./openssh.nix {};
nixosTests.openstack-image-userdata: re-enable
2020-02-03 17:07:57 +00:00
openstack-image-userdata = (handleTestOn ["x86_64-linux"] ./openstack-image.nix {}).userdata or {};
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 14:09:48 +00:00
openstack-image-metadata = (handleTestOn ["x86_64-linux"] ./openstack-image.nix {}).metadata or {};
nixos/orangefs: add test
2019-08-20 23:27:14 +01:00
orangefs = handleTest ./orangefs.nix {};
mention the os-prober test in pkgs.os-prober.passthru.tests
2019-06-09 19:26:05 +01:00
os-prober = handleTestOn ["x86_64-linux"] ./os-prober.nix {};
nixos/tests: add osrm-backend test
2019-01-05 12:13:10 +00:00
osrm-backend = handleTest ./osrm-backend.nix {};
nixos/overlayfs: add test
2019-01-23 09:19:23 +00:00
overlayfs = handleTest ./overlayfs.nix {};
nixos/packagekit: add test
2019-04-24 09:45:29 +01: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 11:30:07 +00: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 16:45:26 +00:00
pam-u2f = handleTest ./pam-u2f.nix {};
nixos/tests/all-tests.nix: add pantheon
2019-01-24 22:33:05 +00:00
pantheon = handleTest ./pantheon.nix {};
paperless service: init
2019-01-27 14:26:31 +00:00
paperless = handleTest ./paperless.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 11:30:07 +00: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 21:07:05 +01:00
php = handleTest ./php {};
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 11:30:07 +00:00
plasma5 = handleTest ./plasma5.nix {};
plotinus = handleTest ./plotinus.nix {};
nixos/virtualisation.podman: Init module
2020-04-20 09:37:53 +01:00
podman = handleTest ./podman.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 11:30:07 +00:00
postgis = handleTest ./postgis.nix {};
postgresql = handleTest ./postgresql.nix {};
nixos/postgresql-wal-receiver: add module (#63799)
2019-08-11 18:09:42 +01: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 11:30:07 +00: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 05:26:54 +01: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 11:30:07 +00:00
predictable-interface-names = handleTest ./predictable-interface-names.nix {};
printing = handleTest ./printing.nix {};
prometheus = handleTest ./prometheus.nix {};
prometheus-exporters = handleTest ./prometheus-exporters.nix {};
nixos/tests: move ejabberd and prosody test to xmpp folder
2019-06-15 10:16:28 +01:00
prosody = handleTest ./xmpp/prosody.nix {};
nixos/tests/prosodyMysql: add check work prosody with MySQL database
2019-06-15 10:58:00 +01: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 11:30:07 +00:00
proxy = handleTest ./proxy.nix {};
quagga = handleTest ./quagga.nix {};
nixos/quorum: init
2020-03-22 16:26:55 +00: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 11:30:07 +00:00
rabbitmq = handleTest ./rabbitmq.nix {};
nixos/radarr: Add test for radarr to ensure startup
2019-01-24 22:09:21 +00: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 11:30:07 +00:00
radicale = handleTest ./radicale.nix {};
nixos/redis: add test
2019-08-31 19:17:33 +01: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 11:30:07 +00:00
redmine = handleTest ./redmine.nix {};
nixos/tests/restic.nix: add test
2020-01-30 21:31:52 +00:00
restic = handleTest ./restic.nix {};
roundcube: apply code review suggestions
2018-11-28 16:33:26 +00: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 11:30:07 +00: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 10:33:43 +01: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 11:30:07 +00:00
rsyslogd = handleTest ./rsyslogd.nix {};
runInMachine = handleTest ./run-in-machine.nix {};
rxe = handleTest ./rxe.nix {};
samba = handleTest ./samba.nix {};
nixos/sanoid, nixos/syncoid: init module and test
2019-10-27 03:37:30 +00:00
sanoid = handleTest ./sanoid.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 11:30:07 +00:00
sddm = handleTest ./sddm.nix {};
nixos/service-runner.nix: Allow quotes in commands + test
2020-02-28 11:17:01 +00:00
service-runner = handleTest ./service-runner.nix {};
nixos/tests: add shiori to all-tests.nix
2019-11-08 17:17:08 +00:00
shiori = handleTest ./shiori.nix {};
nixosTests.signal-desktop: add test
2019-05-22 23:50:51 +01: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 11:30:07 +00:00
simple = handleTest ./simple.nix {};
slurm = handleTest ./slurm.nix {};
smokeping = handleTest ./smokeping.nix {};
snapper = handleTest ./snapper.nix {};
solr = handleTest ./solr.nix {};
nixos/spacecookie: add service module and test
2019-05-24 20:17:51 +01:00
spacecookie = handleTest ./spacecookie.nix {};
spike: add test to nixosTests
2020-04-22 13:40:38 +01:00
spike = handleTest ./spike.nix {};
nixos/sonarr: Add test for sonarr to ensure startup
2019-01-24 22:08:16 +00:00
sonarr = handleTest ./sonarr.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 11:30:07 +00:00
strongswan-swanctl = handleTest ./strongswan-swanctl.nix {};
sudo = handleTest ./sudo.nix {};
switchTest = handleTest ./switch-test.nix {};
nixos/sympa: init module
2019-07-06 19:56:30 +01:00
sympa = handleTest ./sympa.nix {};
nixos/syncthing: add options for declarative device/folder config
2019-04-21 22:05:07 +01:00
syncthing-init = handleTest ./syncthing-init.nix {};
syncthing-relay module: init
2018-11-17 14:02:00 +00: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 11:30:07 +00:00
systemd = handleTest ./systemd.nix {};
nixos/tests: add systemd-analyze test
2019-11-24 23:03:55 +00:00
systemd-analyze = handleTest ./systemd-analyze.nix {};
nixos/systemd-boot: Add basic test
2020-04-11 21:38:55 +01:00
systemd-boot = handleTestOn ["x86_64-linux"] ./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 14:26:10 +00:00
systemd-confinement = handleTest ./systemd-confinement.nix {};
nixos/systemd: migrate systemd-timesync state when required Somewhen between systemd v239 and v242 upstream decided to no longer run a few system services with `DyanmicUser=1` but failed to provide a migration path for all the state those services left behind. For the case of systemd-timesync the state has to be moved from /var/lib/private/systemd/timesync to /var/lib/systemd/timesync if /var/lib/systemd/timesync is currently a symlink. We only do this if the stateVersion is still below 19.09 to avoid starting to have an ever growing activation script for (then) ancient systemd migrations that are no longer required. See https://github.com/systemd/systemd/issues/12131 for details about the missing migration path and related discussion.
2019-05-15 10:05:37 +01:00
systemd-timesyncd = handleTest ./systemd-timesyncd.nix {};
nixos/networkd: add test for VRF configurations
2020-01-25 15:46:55 +00:00
systemd-networkd-vrf = handleTest ./systemd-networkd-vrf.nix {};
nixos/networkd: test routingPolicyRules with a nixos vm test
2020-02-29 18:34:48 +00:00
systemd-networkd = handleTest ./systemd-networkd.nix {};
systemd-networkd: add DHCPServer test
2019-11-16 11:13:51 +00: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 14:12:19 +01:00
systemd-networkd-ipv6-prefix-delegation = handleTest ./systemd-networkd-ipv6-prefix-delegation.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 18:55:41 +00:00
systemd-nspawn = handleTest ./systemd-nspawn.nix {};
tests/pdns-recursor: add
2019-04-04 19:38:56 +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 11:30:07 +00:00
taskserver = handleTest ./taskserver.nix {};
nixos/telegraf: add test
2019-01-21 11:30:11 +00:00
telegraf = handleTest ./telegraf.nix {};
nixos/tiddlywiki: init Service that runs TiddlyWiki nodejs server
2019-04-29 21:46:00 +01:00
tiddlywiki = handleTest ./tiddlywiki.nix {};
nixos/tests/timezone: port to python
2019-12-02 22:28:53 +00:00
timezone = handleTest ./timezone.nix {};
nixos: add test for tinydns
2019-05-16 22:42:02 +01: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 11:30:07 +00:00
tor = handleTest ./tor.nix {};
nixos/traefik: add test
2020-04-06 07:21:35 +01:00
# traefik test relies on docker-containers
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 11:30:07 +00:00
transmission = handleTest ./transmission.nix {};
tests: adding trac
2019-11-03 16:24:22 +00:00
trac = handleTest ./trac.nix {};
trilium: Pin platforms to x86_64 linux
2019-12-22 13:34:54 +00:00
trilium-server = handleTestOn ["x86_64-linux"] ./trilium-server.nix {};
tests: adding trezord
2019-08-16 16:00:07 +01:00
trezord = handleTest ./trezord.nix {};
nixos/trickster: add test
2019-11-01 10:03:23 +00:00
trickster = handleTest ./trickster.nix {};
nixosTests.tuptime: init test
2020-03-24 22:45:49 +00:00
tuptime = handleTest ./tuptime.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 11:30:07 +00:00
udisks2 = handleTest ./udisks2.nix {};
nixos/tests: add unit-php test
2020-04-16 21:08:00 +01: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 11:30:07 +00:00
upnp = handleTest ./upnp.nix {};
nixos: add test for uwsgi
2019-05-27 22:03:22 +01:00
uwsgi = handleTest ./uwsgi.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 11:30:07 +00:00
vault = handleTest ./vault.nix {};
victoriametrics: add module, tests
2020-01-19 17:55:56 +00: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 11:30:07 +00:00
virtualbox = handleTestOn ["x86_64-linux"] ./virtualbox.nix {};
tests/wireguard: init wg-quick - Duplicate and adapt the existing default wireguard test for wg-quick - Pull common setup code out into a seperate file
2019-11-28 08:32:13 +00:00
wg-quick = handleTest ./wireguard/wg-quick.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 12:20:38 +00:00
wireguard = handleTest ./wireguard {};
wireguard: add generatePrivateKeyFile option + test Ideally, private keys never leave the host they're generated on - like SSH. Setting generatePrivateKeyFile to true causes the PK to be generate automatically.
2019-04-24 03:30:05 +01:00
wireguard-generated = handleTest ./wireguard/generated.nix {};
wireguard: add creation and destination namespaces The two new options make it possible to create the interface in one namespace and move it to a different one, as explained at https://www.wireguard.com/netns/.
2019-09-19 21:54:38 +01:00
wireguard-namespaces = handleTest ./wireguard/namespaces.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 11:30:07 +00:00
wordpress = handleTest ./wordpress.nix {};
nixosTests.xandikos: init
2019-12-14 00:17:49 +00: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 11:30:07 +00:00
xautolock = handleTest ./xautolock.nix {};
xfce = handleTest ./xfce.nix {};
xmonad = handleTest ./xmonad.nix {};
xrdp = handleTest ./xrdp.nix {};
xss-lock = handleTest ./xss-lock.nix {};
yabar = handleTest ./yabar.nix {};
nixos/yggdrasil: add service
2019-06-27 16:56:10 +01:00
yggdrasil = handleTest ./yggdrasil.nix {};
nixosTests.zfs: Add to all-tests.nix
2020-02-03 17:33:26 +00:00
zfs = handleTest ./zfs.nix {};
zsh-history: Add tests
2019-12-13 20:47:15 +00: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 11:30:07 +00:00
zookeeper = handleTest ./zookeeper.nix {};
}
Reference in New Issue Copy Permalink