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

307 lines
15 KiB
Nix
Raw Normal View History

tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
{ system, pkgs, callTest }:
# The return value of this function will be an attrset with arbitrary depth and
# the `anything` returned by callTest at its test leafs.
# The tests not supported by `system` will be replaced with `{}`, so that
meta.tests: rename into passthru.tests Nix currently rejects derivations in `meta` values. This works around that limitation by using `passthru` instead. Closes https://github.com/NixOS/nixpkgs/issues/50230
2018-11-11 14:55:23 +01:00
# `passthru.tests` can contain links to those without breaking on architectures
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
# where said tests are unsupported.
# Example callTest that just extracts the derivation from the test:
# callTest = t: t.test;
with pkgs.lib;
let
discoverTests = val:
if !isAttrs val then val
else if hasAttr "test" val then callTest val
else mapAttrs (n: s: discoverTests s) val;
handleTest = path: args:
discoverTests (import path ({ inherit system pkgs; } // args));
handleTestOn = systems: path: args:
if elem system systems then handleTest path args
else {};
in
{
nixos/3proxy: init
2019-10-10 13:56:05 +02:00
_3proxy = handleTest ./3proxy.nix {};
tests: disable some broken tests and/or restrict to x86_64
2018-11-11 13:27:58 +01:00
acme = handleTestOn ["x86_64-linux"] ./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 12:30:07 +01:00
atd = handleTest ./atd.nix {};
automysqlinit: init at 3.0_rc6
2019-04-13 01:06:11 +02:00
automysqlbackup = handleTest ./automysqlbackup.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
avahi = handleTest ./avahi.nix {};
nixos/tests: add babeld
2019-10-12 01:30:55 +02:00
babeld = handleTest ./babeld.nix {};
tests: disable some broken tests and/or restrict to x86_64
2018-11-11 13:27:58 +01:00
bcachefs = handleTestOn ["x86_64-linux"] ./bcachefs.nix {}; # linux-4.18.2018.10.12 is unsupported on aarch64
nixos/beanstalkd: new service for existing package (#55953)
2019-02-22 14:10:02 +01:00
beanstalkd = handleTest ./beanstalkd.nix {};
nixosTests.bees: port to python
2019-11-24 01:10:17 +01:00
bees = handleTest ./bees.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
bind = handleTest ./bind.nix {};
bittorrent = handleTest ./bittorrent.nix {};
#blivet = handleTest ./blivet.nix {}; # broken since 2017-07024
tests: disable some broken tests and/or restrict to x86_64
2018-11-11 13:27:58 +01:00
boot = handleTestOn ["x86_64-linux"] ./boot.nix {}; # syslinux is unsupported on aarch64
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
boot-stage1 = handleTest ./boot-stage1.nix {};
borgbackup = handleTest ./borgbackup.nix {};
buildbot = handleTest ./buildbot.nix {};
nixos/caddy: add tests (#70778)
2019-10-09 13:32:03 +02:00
caddy = handleTest ./caddy.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
cadvisor = handleTestOn ["x86_64-linux"] ./cadvisor.nix {};
nixos/cassandra: Reenable tests
2019-04-22 18:06:40 +02:00
cassandra = handleTest ./cassandra.nix {};
nixos/ceph: Rename old ceph test and add new multi-node test to all-tests.nix
2019-11-01 13:12:18 +01:00
ceph-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 12:30:07 +01: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 15:06:53 +01:00
clickhouse = handleTest ./clickhouse.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
cloud-init = handleTest ./cloud-init.nix {};
codimd = handleTest ./codimd.nix {};
nixos/consul: register test
2019-11-24 15:08:53 +01:00
consul = handleTest ./consul.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
containers-bridge = handleTest ./containers-bridge.nix {};
nixos/containers: add 'ephemeral' option
2019-08-18 21:37:38 +02:00
containers-ephemeral = handleTest ./containers-ephemeral.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
containers-extra_veth = handleTest ./containers-extra_veth.nix {};
containers-hosts = handleTest ./containers-hosts.nix {};
containers-imperative = handleTest ./containers-imperative.nix {};
nixos/containers-ip: Test both ipv4 and ipv6 in the same script
2019-11-26 00:44:12 +01:00
containers-ip = handleTest ./containers-ip.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
containers-macvlans = handleTest ./containers-macvlans.nix {};
containers-physical_interfaces = handleTest ./containers-physical_interfaces.nix {};
nixosTests.containers-portforward: add to all-tests.nix
2019-12-10 20:34:37 +01:00
containers-portforward = handleTest ./containers-portforward.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
containers-restart_networking = handleTest ./containers-restart_networking.nix {};
containers-tmpfs = handleTest ./containers-tmpfs.nix {};
nixos/tests: Reenable couchdb Works just fine in current master
2019-07-24 20:48:43 +02: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 12:30:07 +01:00
deluge = handleTest ./deluge.nix {};
dhparams = handleTest ./dhparams.nix {};
dnscrypt-proxy = handleTestOn ["x86_64-linux"] ./dnscrypt-proxy.nix {};
docker = handleTestOn ["x86_64-linux"] ./docker.nix {};
NixOS: Run Docker containers as declarative systemd services (#55179) * WIP: Run Docker containers as declarative systemd services * PR feedback round 1 * docker-containers: add environment, ports, user, workdir options * docker-containers: log-driver, string->str, line wrapping * ExecStart instead of script wrapper, %n for container name * PR feedback: better description and example formatting * Fix docbook formatting (oops) * Use a list of strings for ports, expand documentation * docker-continers: add a simple nixos test * waitUntilSucceeds to avoid potential weird async issues * Don't enable docker daemon unless we actually need it * PR feedback: leave ExecReload undefined
2019-03-24 23:59:09 +01:00
docker-containers = handleTestOn ["x86_64-linux"] ./docker-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 12:30:07 +01: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 19:04:28 +01:00
documize = handleTest ./documize.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
dovecot = handleTest ./dovecot.nix {};
# 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 11:16:28 +02:00
ejabberd = handleTest ./xmpp/ejabberd.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
elk = handleTestOn ["x86_64-linux"] ./elk.nix {};
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 01:46:21 +02: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 15:06:32 +01: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 12:30:07 +01:00
ferm = handleTest ./ferm.nix {};
firefox = handleTest ./firefox.nix {};
firewall = handleTest ./firewall.nix {};
nixos/fish: generate autocompletions from man pages
2018-12-17 20:12:09 +01:00
fish = handleTest ./fish.nix {};
nixos/flannel: fix flannel nixos test, add test to all-tests.nix
2019-02-12 18:26:08 +01:00
flannel = handleTestOn ["x86_64-linux"] ./flannel.nix {};
fluentd: add simple test
2019-07-29 17:35:27 +02:00
fluentd = handleTest ./fluentd.nix {};
nixos.tests.fontconfig-default-fonts: init Make sure the fonts.enableDefaultFonts option works.
2019-08-29 14:02:20 +02:00
fontconfig-default-fonts = handleTest ./fontconfig-default-fonts.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
fsck = handleTest ./fsck.nix {};
nixos/gotify: init module and test
2019-10-25 15:14:57 +02:00
gotify-server = handleTest ./gotify-server.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
gitea = handleTest ./gitea.nix {};
gitlab = handleTest ./gitlab.nix {};
gitolite = handleTest ./gitolite.nix {};
gitolite: wrap gitolite-shell git wasn't found when used with services.fcgiwrap for http auth
2019-12-05 00:10:57 +01:00
gitolite-fcgiwrap = handleTest ./gitolite-fcgiwrap.nix {};
nixos/glusterfs: add test
2019-08-17 01:28:43 +02:00
glusterfs = handleTest ./glusterfs.nix {};
nixosTests.gnome{xorg}: re-enable on aarch64
2019-08-07 04:01:17 +02:00
gnome3-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 01:56:21 +01: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 12:30:07 +01:00
gocd-agent = handleTest ./gocd-agent.nix {};
gocd-server = handleTest ./gocd-server.nix {};
nixosTests.graphene: init
2019-05-17 03:29:17 +02:00
google-oslogin = handleTest ./google-oslogin {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
grafana = handleTest ./grafana.nix {};
graphite = handleTest ./graphite.nix {};
nixos/graylog: add test Basic test which confirms new inputs can be created and that messages can be sent to a UDP-GELF input using `netcat`. This test requires 4GB of RAM to avoid issues due insufficient memory (please refer to `nixos/tests/elk.nix` for a detailed explanation of the issue) for elasticsearch. Also it's ensured that elasticsearch has an open HTTP port for communication when starting `graylog`. This is a workaround to ensure that all services are started in proper order, even in test environments with less power. However this shouldn't be implemented in the `nixos/graylog` module as this might be harmful when using elasticsearch clusters that require e.g. authentication and/or run on different servers.
2019-07-09 02:01:43 +02:00
graylog = handleTest ./graylog.nix {};
nixosTests.gvisor: add test for gvisor and gvisor as a Docker runtime
2019-11-27 08:01:46 +01:00
gvisor = handleTest ./gvisor.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
hadoop.hdfs = handleTestOn [ "x86_64-linux" ] ./hadoop/hdfs.nix {};
hadoop.yarn = handleTestOn [ "x86_64-linux" ] ./hadoop/yarn.nix {};
tests: handbrake: test transcoding to MKV and MP4.
2018-11-12 07:45:00 +01:00
handbrake = handleTestOn ["x86_64-linux"] ./handbrake.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
haproxy = handleTest ./haproxy.nix {};
nixos/tests: re-enable hardened test Has been okay since 62623b60d5fed91ac676d6f4a70a12570090d513
2019-01-06 14:04:41 +01:00
hardened = handleTest ./hardened.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
hibernate = handleTest ./hibernate.nix {};
hitch = handleTest ./hitch {};
hocker-fetchdocker = handleTest ./hocker-fetchdocker {};
home-assistant = handleTest ./home-assistant.nix {};
hound = handleTest ./hound.nix {};
hydra = handleTest ./hydra {};
i3wm = handleTest ./i3wm.nix {};
nixos/icingaweb: Fix module path; Add test
2019-07-07 03:03:59 +02:00
icingaweb2 = handleTest ./icingaweb2.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
iftop = handleTest ./iftop.nix {};
nixos/tests/all-tests.nix: Fix incron test path
2018-11-14 23:51:15 +01:00
incron = handleTest ./incron.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
influxdb = handleTest ./influxdb.nix {};
initrd-network-ssh = handleTest ./initrd-network-ssh {};
initrdNetwork = handleTest ./initrd-network.nix {};
installer = handleTest ./installer.nix {};
ipv6 = handleTest ./ipv6.nix {};
nixos/jackett: Add test for jackett to ensure startup
2019-01-25 07:09:36 +01:00
jackett = handleTest ./jackett.nix {};
nixos/jellyfin: add test to all-tests.nix
2019-05-01 11:57:34 +02:00
jellyfin = handleTest ./jellyfin.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
jenkins = handleTest ./jenkins.nix {};
kafka: Add test for 2.2 Also add back tests, don't seem broken anymore. This is just fine: nix-build ./nixos/release.nix -A tests.kafka.kafka_2_1.x86_64-linux -A tests.kafka.kafka_2_2.x86_64-linux
2019-04-01 14:39:25 +02:00
kafka = handleTest ./kafka.nix {};
nixos/keepalived: add test
2019-12-22 08:45:31 +01:00
keepalived = handleTest ./keepalived.nix {};
nixos/tests/kerberos: fix evaluation
2019-01-11 05:36:51 +01:00
kerberos = handleTest ./kerberos/default.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
kernel-latest = handleTest ./kernel-latest.nix {};
kernel-lts = handleTest ./kernel-lts.nix {};
linux: Add testing test
2019-04-01 14:31:36 +02:00
kernel-testing = handleTest ./kernel-testing.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
keymap = handleTest ./keymap.nix {};
nixos/knot: init
2019-03-13 01:12:56 +01:00
knot = handleTest ./knot.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
kubernetes.dns = handleTestOn ["x86_64-linux"] ./kubernetes/dns.nix {};
# kubernetes.e2e should eventually replace kubernetes.rbac when it works
#kubernetes.e2e = handleTestOn ["x86_64-linux"] ./kubernetes/e2e.nix {};
kubernetes.rbac = handleTestOn ["x86_64-linux"] ./kubernetes/rbac.nix {};
latestKernel.login = handleTest ./login.nix { latestKernel = true; };
ldap = handleTest ./ldap.nix {};
leaps = handleTest ./leaps.nix {};
nixos/lidarr: Add test for lidarr to ensure startup
2019-01-24 23:09:42 +01:00
lidarr = handleTest ./lidarr.nix {};
nixos/release-combined: re-enable lightdm test This has been tested in the Pantheon test for a year now and it does fine on hydra.
2019-08-07 00:29:50 +02:00
lightdm = handleTest ./lightdm.nix {};
nixos/limesurvey: add basic nixos test
2019-03-16 13:24:23 +01:00
limesurvey = handleTest ./limesurvey.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
login = handleTest ./login.nix {};
nixos/tests: add test for loki
2019-06-27 18:11:09 +02:00
loki = handleTest ./loki.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
#logstash = handleTest ./logstash.nix {};
lorri: init at version unstable-2019-10-30 Includes user service (nixos/modules/services/development/lorri) that starts on demand.
2019-11-05 11:57:05 +01:00
lorri = handleTest ./lorri/default.nix {};
nixos/tests/magnetico: port to python
2019-11-13 19:17:32 +01:00
magnetico = handleTest ./magnetico.nix {};
nixos/mailcatcher: add nixos test
2019-03-27 12:35:24 +01:00
mailcatcher = handleTest ./mailcatcher.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
mathics = handleTest ./mathics.nix {};
nixos/matomo: add test
2019-10-04 22:38:58 +02:00
matomo = handleTest ./matomo.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
matrix-synapse = handleTest ./matrix-synapse.nix {};
nixos/mediawiki: init service to replace httpd subservice
2019-06-06 03:19:11 +02:00
mediawiki = handleTest ./mediawiki.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
memcached = handleTest ./memcached.nix {};
mesos = handleTest ./mesos.nix {};
tests: adding metabase service test
2019-08-18 09:28:16 +02:00
metabase = handleTest ./metabase.nix {};
miniflux: add service
2018-12-21 19:36:58 +01:00
miniflux = handleTest ./miniflux.nix {};
minio: add test to nixos/tests/all-tests.nix
2019-02-05 17:38:34 +01:00
minio = handleTest ./minio.nix {};
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 11:29:25 +01: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 12:30:07 +01:00
misc = handleTest ./misc.nix {};
nixos/moin: init
2019-07-16 01:06:19 +02:00
moinmoin = handleTest ./moinmoin.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
mongodb = handleTest ./mongodb.nix {};
nixos/moodle: init service
2019-06-21 16:09:15 +02:00
moodle = handleTest ./moodle.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
morty = handleTest ./morty.nix {};
nixos/mosquitto: add test
2019-04-24 10:23:13 +02:00
mosquitto = handleTest ./mosquitto.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
mpd = handleTest ./mpd.nix {};
mumble = handleTest ./mumble.nix {};
munin = handleTest ./munin.nix {};
mutableUsers = handleTest ./mutable-users.nix {};
tests: add mxisd to all-tests
2019-05-18 22:18:01 +02:00
mxisd = handleTest ./mxisd.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
mysql = handleTest ./mysql.nix {};
mysqlBackup = handleTest ./mysql-backup.nix {};
mysqlReplication = handleTest ./mysql-replication.nix {};
nagios: add nixos test
2019-12-30 13:00:00 +01: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 12:30:07 +01:00
nat.firewall = handleTest ./nat.nix { withFirewall = true; };
nat.firewall-conntrack = handleTest ./nat.nix { withFirewall = true; withConntrackHelpers = true; };
nat.standalone = handleTest ./nat.nix { withFirewall = false; };
nixos/ndppd: register test
2019-02-03 16:47:01 +01:00
ndppd = handleTest ./ndppd.nix {};
neo4j: add neo4j test
2019-02-01 14:29:54 +01:00
neo4j = handleTest ./neo4j.nix {};
nixos: Add test that demonstrates how to use nesting.clone This is actually very useful. Allows you to test switch-to-configuration nesting.children is still currently still broken as it will throw away 'too much' of the config, including the modules that make nixos tests work in the first place. But that's something for another time.
2019-05-26 00:35:29 +02:00
nesting = handleTest ./nesting.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
netdata = handleTest ./netdata.nix {};
networking.networkd = handleTest ./networking.nix { networkd = true; };
networking.scripted = handleTest ./networking.nix { networkd = false; };
# TODO: put in networking.nix after the test becomes more complete
networkingProxy = handleTest ./networking-proxy.nix {};
nextcloud = handleTest ./nextcloud {};
nexus = handleTest ./nexus.nix {};
nixos/nfs: test nfs with kerberos authentication
2019-11-27 15:37:27 +01:00
# TODO: Test nfsv3 + Kerberos
nfs3 = handleTest ./nfs { version = 3; };
nfs4 = handleTest ./nfs { version = 4; };
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
nghttpx = handleTest ./nghttpx.nix {};
nginx = handleTest ./nginx.nix {};
nginx: Clear Last-Modified if ETag is from store This is what I've suspected a while ago[1]: > Heads-up everyone: After testing this in a few production instances, > it seems that some browsers still get cache hits for new store paths > (and changed contents) for some reason. I highly suspect that it might > be due to the last-modified header (as mentioned in [2]). > > Going to test this with last-modified disabled for a little while and > if this is the case I think we should improve that patch by disabling > last-modified if serving from a store path. Much earlier[2] when I reviewed the patch, I wrote this: > Other than that, it looks good to me. > > However, I'm not sure what we should do with Last-Modified header. > From RFC 2616, section 13.3.4: > > - If both an entity tag and a Last-Modified value have been > provided by the origin server, SHOULD use both validators in > cache-conditional requests. This allows both HTTP/1.0 and > HTTP/1.1 caches to respond appropriately. > > I'm a bit nervous about the SHOULD here, as user agents in the wild > could possibly just use Last-Modified and use the cached content > instead. Unfortunately, I didn't pursue this any further back then because @pbogdan noted[3] the following: > Hmm, could they (assuming they are conforming): > > * If an entity tag has been provided by the origin server, MUST > use that entity tag in any cache-conditional request (using If- > Match or If-None-Match). Since running with this patch in some deployments, I found that both Firefox and Chrome/Chromium do NOT re-validate against the ETag if the Last-Modified header is still the same. So I wrote a small NixOS VM test with Geckodriver to have a test case which is closer to the real world and I indeed was able to reproduce this. Whether this is actually a bug in Chrome or Firefox is an entirely different issue and even IF it is the fault of the browsers and it is fixed at some point, we'd still need to handle this for older browser versions. Apart from clearing the header, I also recreated the patch by using a plain "git diff" with a small description on top. This should make it easier for future authors to work on that patch. [1]: https://github.com/NixOS/nixpkgs/pull/48337#issuecomment-495072764 [2]: https://github.com/NixOS/nixpkgs/pull/48337#issuecomment-451644084 [3]: https://github.com/NixOS/nixpkgs/pull/48337#issuecomment-451646135 Signed-off-by: aszlig <aszlig@nix.build>
2019-12-30 14:06:00 +01:00
nginx-etag = handleTest ./nginx-etag.nix {};
nixos/tests: add nginx-sso basic functionality test
2018-12-28 11:41:52 +01: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 12:30:07 +01:00
nix-ssh-serve = handleTest ./nix-ssh-serve.nix {};
nixos-generate-config: enable overriding configuration.nix
2019-08-07 18:04:18 +02:00
nixos-generate-config = handleTest ./nixos-generate-config.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
novacomd = handleTestOn ["x86_64-linux"] ./novacomd.nix {};
nsd = handleTest ./nsd.nix {};
nixos/nzbget: fix broken service, add a nixos test, as well as some general improvements
2019-04-22 14:06:33 +02:00
nzbget = handleTest ./nzbget.nix {};
openarena: add test
2019-10-22 16:20:56 +02:00
openarena = handleTest ./openarena.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
openldap = handleTest ./openldap.nix {};
opensmtpd = handleTest ./opensmtpd.nix {};
openssh = handleTest ./openssh.nix {};
Rename `novaImage` to `openstackImage` People don't necessary know `nova` is related to Openstack (it is a component of Openstack). So, it is more explicit to call it `openstackImage`.
2019-01-28 15:09:48 +01:00
# openstack-image-userdata doesn't work in a sandbox as the simulated openstack instance needs network access
#openstack-image-userdata = (handleTestOn ["x86_64-linux"] ./openstack-image.nix {}).userdata or {};
openstack-image-metadata = (handleTestOn ["x86_64-linux"] ./openstack-image.nix {}).metadata or {};
nixos/orangefs: add test
2019-08-21 00:27:14 +02:00
orangefs = handleTest ./orangefs.nix {};
mention the os-prober test in pkgs.os-prober.passthru.tests
2019-06-09 20:26:05 +02:00
os-prober = handleTestOn ["x86_64-linux"] ./os-prober.nix {};
nixos/tests: add osrm-backend test
2019-01-05 13:13:10 +01:00
osrm-backend = handleTest ./osrm-backend.nix {};
nixos/overlayfs: add test
2019-01-23 10:19:23 +01:00
overlayfs = handleTest ./overlayfs.nix {};
nixos/packagekit: add test
2019-04-24 10:45:29 +02:00
packagekit = handleTest ./packagekit.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
pam-oath-login = handleTest ./pam-oath-login.nix {};
nixos/pam: refactor U2F, docs about u2f_keys path (#54756) * change enableU2F option to u2f.* set * add few u2f options (not all) to customize pam-u2f module * document default u2f_keys locations Co-authored-by: Tomasz Czyż <tomasz.czyz@gmail.com> Co-authored-by: Arda Xi <arda@ardaxi.com>
2019-01-29 17:45:26 +01:00
pam-u2f = handleTest ./pam-u2f.nix {};
nixos/tests/all-tests.nix: add pantheon
2019-01-24 23:33:05 +01:00
pantheon = handleTest ./pantheon.nix {};
paperless service: init
2019-01-27 15:26:31 +01:00
paperless = handleTest ./paperless.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
peerflix = handleTest ./peerflix.nix {};
pgjwt = handleTest ./pgjwt.nix {};
pgmanage = handleTest ./pgmanage.nix {};
php-pcre = handleTest ./php-pcre.nix {};
plasma5 = handleTest ./plasma5.nix {};
plotinus = handleTest ./plotinus.nix {};
postgis = handleTest ./postgis.nix {};
postgresql = handleTest ./postgresql.nix {};
nixos/postgresql-wal-receiver: add module (#63799)
2019-08-11 19:09:42 +02:00
postgresql-wal-receiver = handleTest ./postgresql-wal-receiver.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
powerdns = handleTest ./powerdns.nix {};
nixos/tests/pppd: init This test creates a PPPoE link between two machines, and verifies that the machines can ping each other.
2019-10-15 06:26:54 +02:00
pppd = handleTest ./pppd.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
predictable-interface-names = handleTest ./predictable-interface-names.nix {};
printing = handleTest ./printing.nix {};
prometheus = handleTest ./prometheus.nix {};
prometheus-exporters = handleTest ./prometheus-exporters.nix {};
nixos/tests: move ejabberd and prosody test to xmpp folder
2019-06-15 11:16:28 +02:00
prosody = handleTest ./xmpp/prosody.nix {};
nixos/tests/prosodyMysql: add check work prosody with MySQL database
2019-06-15 11:58:00 +02:00
prosodyMysql = handleTest ./xmpp/prosody-mysql.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
proxy = handleTest ./proxy.nix {};
quagga = handleTest ./quagga.nix {};
rabbitmq = handleTest ./rabbitmq.nix {};
nixos/radarr: Add test for radarr to ensure startup
2019-01-24 23:09:21 +01:00
radarr = handleTest ./radarr.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
radicale = handleTest ./radicale.nix {};
nixos/redis: add test
2019-08-31 20:17:33 +02:00
redis = handleTest ./redis.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
redmine = handleTest ./redmine.nix {};
roundcube: apply code review suggestions
2018-11-28 17:33:26 +01:00
roundcube = handleTest ./roundcube.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
rspamd = handleTest ./rspamd.nix {};
rss2email module: init Also adding `system-sendmail` package for sharing the code with other modules or packages needing it.
2018-10-27 11:33:43 +02:00
rss2email = handleTest ./rss2email.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
rsyslogd = handleTest ./rsyslogd.nix {};
runInMachine = handleTest ./run-in-machine.nix {};
rxe = handleTest ./rxe.nix {};
samba = handleTest ./samba.nix {};
sddm = handleTest ./sddm.nix {};
nixos/tests: add shiori to all-tests.nix
2019-11-08 18:17:08 +01:00
shiori = handleTest ./shiori.nix {};
nixosTests.signal-desktop: add test
2019-05-23 00:50:51 +02:00
signal-desktop = handleTest ./signal-desktop.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
simple = handleTest ./simple.nix {};
slurm = handleTest ./slurm.nix {};
smokeping = handleTest ./smokeping.nix {};
snapper = handleTest ./snapper.nix {};
solr = handleTest ./solr.nix {};
nixos/spacecookie: add service module and test
2019-05-24 21:17:51 +02:00
spacecookie = handleTest ./spacecookie.nix {};
nixos/sonarr: Add test for sonarr to ensure startup
2019-01-24 23:08:16 +01: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 12:30:07 +01:00
strongswan-swanctl = handleTest ./strongswan-swanctl.nix {};
sudo = handleTest ./sudo.nix {};
switchTest = handleTest ./switch-test.nix {};
nixos/syncthing: add options for declarative device/folder config
2019-04-21 23:05:07 +02:00
syncthing-init = handleTest ./syncthing-init.nix {};
syncthing-relay module: init
2018-11-17 15:02:00 +01:00
syncthing-relay = handleTest ./syncthing-relay.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
systemd = handleTest ./systemd.nix {};
nixos/tests: add systemd-analyze test
2019-11-25 00:03:55 +01:00
systemd-analyze = handleTest ./systemd-analyze.nix {};
nixos/systemd-chroot: Rename chroot to confinement Quoting @edolstra from [1]: I don't really like the name "chroot", something like "confine[ment]" or "restrict" seems better. Conceptually we're not providing a completely different filesystem tree but a restricted view of the same tree. I already used "confinement" as a sub-option and I do agree that "chroot" sounds a bit too specific (especially because not *only* chroot is involved). So this changes the module name and its option to use "confinement" instead of "chroot" and also renames the "chroot.confinement" to "confinement.mode". [1]: https://github.com/NixOS/nixpkgs/pull/57519#issuecomment-472855704 Signed-off-by: aszlig <aszlig@nix.build>
2019-03-14 15:26:10 +01:00
systemd-confinement = handleTest ./systemd-confinement.nix {};
nixos/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 11:05:37 +02:00
systemd-timesyncd = handleTest ./systemd-timesyncd.nix {};
systemd-networkd: add tests (cherry picked from commit ec073e41a0dc8273cd81cf61fa37004310120af2)
2019-06-24 17:36:08 +02:00
systemd-networkd-wireguard = handleTest ./systemd-networkd-wireguard.nix {};
nixosTests.systemd-nspawn: add test This adds a test downloading an nspawn container via http, and ensures sha256sum verification and gpg signature verification work.
2019-11-02 19:55:41 +01:00
systemd-nspawn = handleTest ./systemd-nspawn.nix {};
tests/pdns-recursor: add
2019-04-04 20:38:56 +02:00
pdns-recursor = handleTest ./pdns-recursor.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
taskserver = handleTest ./taskserver.nix {};
nixos/telegraf: add test
2019-01-21 12:30:11 +01:00
telegraf = handleTest ./telegraf.nix {};
nixos/tiddlywiki: init Service that runs TiddlyWiki nodejs server
2019-04-29 22:46:00 +02:00
tiddlywiki = handleTest ./tiddlywiki.nix {};
nixos/tests/timezone: port to python
2019-12-02 23:28:53 +01:00
timezone = handleTest ./timezone.nix {};
nixos: add test for tinydns
2019-05-16 23:42:02 +02:00
tinydns = handleTest ./tinydns.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
tor = handleTest ./tor.nix {};
transmission = handleTest ./transmission.nix {};
tests: adding trac
2019-11-03 17:24:22 +01:00
trac = handleTest ./trac.nix {};
trilium: Pin platforms to x86_64 linux
2019-12-22 14:34:54 +01:00
trilium-server = handleTestOn ["x86_64-linux"] ./trilium-server.nix {};
tests: adding trezord
2019-08-16 17:00:07 +02:00
trezord = handleTest ./trezord.nix {};
nixos/trickster: add test
2019-11-01 11:03:23 +01:00
trickster = handleTest ./trickster.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
udisks2 = handleTest ./udisks2.nix {};
upnp = handleTest ./upnp.nix {};
nixos: add test for uwsgi
2019-05-27 23:03:22 +02: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 12:30:07 +01:00
vault = handleTest ./vault.nix {};
virtualbox = handleTestOn ["x86_64-linux"] ./virtualbox.nix {};
nixos/wireguard: add test After working on the last wireguard bump (#57534), we figured that it's probably a good idea to have a basic test which confirms that a simple VPN with wireguard still works. This test starts two peers with a `wg0` network interface and adds a v4 and a v6 route that goes through `wg0`.
2019-03-17 13:20:38 +01:00
wireguard = handleTest ./wireguard {};
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 04:30:05 +02: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 22:54:38 +02: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 12:30:07 +01:00
wordpress = handleTest ./wordpress.nix {};
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 17:56:10 +02:00
yggdrasil = handleTest ./yggdrasil.nix {};
zsh-history: Add tests
2019-12-13 21:47:15 +01:00
zsh-history = handleTest ./zsh-history.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
zookeeper = handleTest ./zookeeper.nix {};
}
Reference in a new issue Copy permalink