mirrors/nixpkgs
1
0
Fork 1
mirror of https://github.com/NixOS/nixpkgs.git synced 2024-11-19 12:11:28 +00:00
Code Issues Wiki Activity
nixpkgs/nixos/tests/all-tests.nix

239 lines
12 KiB
Nix
Raw Normal View History

tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
{ system, pkgs, callTest }:
# The return value of this function will be an attrset with arbitrary depth and
# the `anything` returned by callTest at its test leafs.
# The tests not supported by `system` will be replaced with `{}`, so that
meta.tests: rename into passthru.tests Nix currently rejects derivations in `meta` values. This works around that limitation by using `passthru` instead. Closes https://github.com/NixOS/nixpkgs/issues/50230
2018-11-11 13:55:23 +00:00
# `passthru.tests` can contain links to those without breaking on architectures
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
# where said tests are unsupported.
# Example callTest that just extracts the derivation from the test:
# callTest = t: t.test;
with pkgs.lib;
let
discoverTests = val:
if !isAttrs val then val
else if hasAttr "test" val then callTest val
else mapAttrs (n: s: discoverTests s) val;
handleTest = path: args:
discoverTests (import path ({ inherit system pkgs; } // args));
handleTestOn = systems: path: args:
if elem system systems then handleTest path args
else {};
in
{
tests: disable some broken tests and/or restrict to x86_64
2018-11-11 12:27:58 +00: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 11:30:07 +00:00
atd = handleTest ./atd.nix {};
avahi = handleTest ./avahi.nix {};
tests: disable some broken tests and/or restrict to x86_64
2018-11-11 12:27:58 +00:00
bcachefs = handleTestOn ["x86_64-linux"] ./bcachefs.nix {}; # linux-4.18.2018.10.12 is unsupported on aarch64
nixos/beanstalkd: new service for existing package (#55953)
2019-02-22 13:10:02 +00:00
beanstalkd = handleTest ./beanstalkd.nix {};
tests: disable some broken tests and/or restrict to x86_64
2018-11-11 12:27:58 +00:00
beegfs = handleTestOn ["x86_64-linux"] ./beegfs.nix {}; # beegfs is unsupported on aarch64
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
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 12:27:58 +00:00
boot = handleTestOn ["x86_64-linux"] ./boot.nix {}; # syslinux is unsupported on aarch64
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
boot-stage1 = handleTest ./boot-stage1.nix {};
borgbackup = handleTest ./borgbackup.nix {};
buildbot = handleTest ./buildbot.nix {};
cadvisor = handleTestOn ["x86_64-linux"] ./cadvisor.nix {};
ceph = handleTestOn ["x86_64-linux"] ./ceph.nix {};
certmgr = handleTest ./certmgr.nix {};
cfssl = handleTestOn ["x86_64-linux"] ./cfssl.nix {};
chromium = (handleTestOn ["x86_64-linux"] ./chromium.nix {}).stable or {};
cjdns = handleTest ./cjdns.nix {};
clickhouse: fix module and package runtime Although the package itself builds fine, the module fails because it tries to log into a non-existant file in `/var/log` which breaks the service. Patching to default config to log to stdout by default fixes the issue. Additionally this is the better solution as NixOS heavily relies on systemd (and thus journald) for logging. Also, the runtime relies on `/etc/localtime` to start, as it's not required by the module system we set UTC as sensitive default when using the module. To ensure that the service's basic functionality is available, a simple NixOS test has been added.
2018-12-19 14:06:53 +00:00
clickhouse = handleTest ./clickhouse.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
cloud-init = handleTest ./cloud-init.nix {};
codimd = handleTest ./codimd.nix {};
containers-bridge = handleTest ./containers-bridge.nix {};
containers-extra_veth = handleTest ./containers-extra_veth.nix {};
containers-hosts = handleTest ./containers-hosts.nix {};
containers-imperative = handleTest ./containers-imperative.nix {};
containers-ipv4 = handleTest ./containers-ipv4.nix {};
containers-ipv6 = handleTest ./containers-ipv6.nix {};
containers-macvlans = handleTest ./containers-macvlans.nix {};
containers-physical_interfaces = handleTest ./containers-physical_interfaces.nix {};
containers-restart_networking = handleTest ./containers-restart_networking.nix {};
containers-tmpfs = handleTest ./containers-tmpfs.nix {};
tests: disable some broken tests and/or restrict to x86_64
2018-11-11 12:27:58 +00:00
#couchdb = handleTest ./couchdb.nix {}; # spidermonkey-1.8.5 is marked as broken
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
deluge = handleTest ./deluge.nix {};
dhparams = handleTest ./dhparams.nix {};
dnscrypt-proxy = handleTestOn ["x86_64-linux"] ./dnscrypt-proxy.nix {};
docker = handleTestOn ["x86_64-linux"] ./docker.nix {};
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 {};
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 {};
elk = handleTestOn ["x86_64-linux"] ./elk.nix {};
env = handleTest ./env.nix {};
etcd = handleTestOn ["x86_64-linux"] ./etcd.nix {};
ferm = handleTest ./ferm.nix {};
firefox = handleTest ./firefox.nix {};
firewall = handleTest ./firewall.nix {};
nixos/fish: generate autocompletions from man pages
2018-12-17 19:12:09 +00:00
fish = handleTest ./fish.nix {};
nixos/flannel: fix flannel nixos test, add test to all-tests.nix
2019-02-12 17:26:08 +00:00
flannel = handleTestOn ["x86_64-linux"] ./flannel.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
flatpak = handleTest ./flatpak.nix {};
fsck = handleTest ./fsck.nix {};
tests: disable some broken tests and/or restrict to x86_64
2018-11-11 12:27:58 +00:00
fwupd = handleTestOn ["x86_64-linux"] ./fwupd.nix {}; # libsmbios is unsupported on aarch64
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
gdk-pixbuf = handleTest ./gdk-pixbuf.nix {};
gitea = handleTest ./gitea.nix {};
gitlab = handleTest ./gitlab.nix {};
gitolite = handleTest ./gitolite.nix {};
gjs = handleTest ./gjs.nix {};
nixos/tests: add google-oslogin test
2018-12-12 12:59:08 +00:00
google-oslogin = handleTest ./google-oslogin {};
tests: disable some broken tests and/or restrict to x86_64
2018-11-11 12:27:58 +00:00
gnome3 = handleTestOn ["x86_64-linux"] ./gnome3.nix {}; # libsmbios is unsupported on aarch64
gnome3-gdm = handleTestOn ["x86_64-linux"] ./gnome3-gdm.nix {}; # libsmbios is unsupported on aarch64
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
gocd-agent = handleTest ./gocd-agent.nix {};
gocd-server = handleTest ./gocd-server.nix {};
grafana = handleTest ./grafana.nix {};
graphite = handleTest ./graphite.nix {};
hadoop.hdfs = handleTestOn [ "x86_64-linux" ] ./hadoop/hdfs.nix {};
hadoop.yarn = handleTestOn [ "x86_64-linux" ] ./hadoop/yarn.nix {};
tests: handbrake: test transcoding to MKV and MP4.
2018-11-12 06:45:00 +00:00
handbrake = handleTestOn ["x86_64-linux"] ./handbrake.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
haproxy = handleTest ./haproxy.nix {};
nixos/tests: re-enable hardened test Has been okay since 62623b60d5fed91ac676d6f4a70a12570090d513
2019-01-06 13:04:41 +00:00
hardened = handleTest ./hardened.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
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 {};
iftop = handleTest ./iftop.nix {};
nixos/tests/all-tests.nix: Fix incron test path
2018-11-14 22:51:15 +00:00
incron = handleTest ./incron.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
influxdb = handleTest ./influxdb.nix {};
initrd-network-ssh = handleTest ./initrd-network-ssh {};
initrdNetwork = handleTest ./initrd-network.nix {};
installer = handleTest ./installer.nix {};
ipv6 = handleTest ./ipv6.nix {};
nixos/jackett: Add test for jackett to ensure startup
2019-01-25 06:09:36 +00:00
jackett = handleTest ./jackett.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
jenkins = handleTest ./jenkins.nix {};
nixos tests: disable kafka for now They consistently fail since openjdk bump with some out-of-space errors. That's not a problem by itself, but each test instance ties a build slot for many hours and consequently they also delay channels as those wait for all builds to finish. Feel free to re-enable when fixed, of course.
2018-12-10 12:19:00 +00:00
#kafka = handleTest ./kafka.nix {}; # broken since openjdk: 8u181 -> 8u192
nixos/tests/kerberos: fix evaluation
2019-01-11 04:36:51 +00:00
kerberos = handleTest ./kerberos/default.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
kernel-latest = handleTest ./kernel-latest.nix {};
kernel-lts = handleTest ./kernel-lts.nix {};
keymap = handleTest ./keymap.nix {};
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 22:09:42 +00:00
lidarr = handleTest ./lidarr.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
#lightdm = handleTest ./lightdm.nix {};
login = handleTest ./login.nix {};
#logstash = handleTest ./logstash.nix {};
mathics = handleTest ./mathics.nix {};
matrix-synapse = handleTest ./matrix-synapse.nix {};
memcached = handleTest ./memcached.nix {};
mesos = handleTest ./mesos.nix {};
minio: add test to nixos/tests/all-tests.nix
2019-02-05 16:38:34 +00:00
minio = handleTest ./minio.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
misc = handleTest ./misc.nix {};
mongodb = handleTest ./mongodb.nix {};
morty = handleTest ./morty.nix {};
mpd = handleTest ./mpd.nix {};
mumble = handleTest ./mumble.nix {};
munin = handleTest ./munin.nix {};
mutableUsers = handleTest ./mutable-users.nix {};
mysql = handleTest ./mysql.nix {};
mysqlBackup = handleTest ./mysql-backup.nix {};
mysqlReplication = handleTest ./mysql-replication.nix {};
nat.firewall = handleTest ./nat.nix { withFirewall = true; };
nat.firewall-conntrack = handleTest ./nat.nix { withFirewall = true; withConntrackHelpers = true; };
nat.standalone = handleTest ./nat.nix { withFirewall = false; };
nixos/ndppd: register test
2019-02-03 15:47:01 +00:00
ndppd = handleTest ./ndppd.nix {};
neo4j: add neo4j test
2019-02-01 13:29:54 +00:00
neo4j = handleTest ./neo4j.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
netdata = handleTest ./netdata.nix {};
networking.networkd = handleTest ./networking.nix { networkd = true; };
networking.scripted = handleTest ./networking.nix { networkd = false; };
# TODO: put in networking.nix after the test becomes more complete
networkingProxy = handleTest ./networking-proxy.nix {};
nextcloud = handleTest ./nextcloud {};
nexus = handleTest ./nexus.nix {};
nfs3 = handleTest ./nfs.nix { version = 3; };
nfs4 = handleTest ./nfs.nix { version = 4; };
nghttpx = handleTest ./nghttpx.nix {};
nginx = handleTest ./nginx.nix {};
nixos/tests: add nginx-sso basic functionality test
2018-12-28 10:41:52 +00:00
nginx-sso = handleTest ./nginx-sso.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
nix-ssh-serve = handleTest ./nix-ssh-serve.nix {};
novacomd = handleTestOn ["x86_64-linux"] ./novacomd.nix {};
nsd = handleTest ./nsd.nix {};
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 14:09:48 +00: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 {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
osquery = handleTest ./osquery.nix {};
nixos/tests: add osrm-backend test
2019-01-05 12:13:10 +00:00
osrm-backend = handleTest ./osrm-backend.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
ostree = handleTest ./ostree.nix {};
pam-oath-login = handleTest ./pam-oath-login.nix {};
nixos/pam: refactor U2F, docs about u2f_keys path (#54756) * change enableU2F option to u2f.* set * add few u2f options (not all) to customize pam-u2f module * document default u2f_keys locations Co-authored-by: Tomasz Czyż <tomasz.czyz@gmail.com> Co-authored-by: Arda Xi <arda@ardaxi.com>
2019-01-29 16:45:26 +00:00
pam-u2f = handleTest ./pam-u2f.nix {};
nixos/tests/all-tests.nix: add pantheon
2019-01-24 22:33:05 +00:00
pantheon = handleTest ./pantheon.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
peerflix = handleTest ./peerflix.nix {};
pgjwt = handleTest ./pgjwt.nix {};
pgmanage = handleTest ./pgmanage.nix {};
php-pcre = handleTest ./php-pcre.nix {};
plasma5 = handleTest ./plasma5.nix {};
plotinus = handleTest ./plotinus.nix {};
postgis = handleTest ./postgis.nix {};
postgresql = handleTest ./postgresql.nix {};
powerdns = handleTest ./powerdns.nix {};
predictable-interface-names = handleTest ./predictable-interface-names.nix {};
printing = handleTest ./printing.nix {};
prometheus = handleTest ./prometheus.nix {};
prometheus-exporters = handleTest ./prometheus-exporters.nix {};
prosody = handleTest ./prosody.nix {};
proxy = handleTest ./proxy.nix {};
quagga = handleTest ./quagga.nix {};
quake3 = handleTest ./quake3.nix {};
rabbitmq = handleTest ./rabbitmq.nix {};
nixos/radarr: Add test for radarr to ensure startup
2019-01-24 22:09:21 +00:00
radarr = handleTest ./radarr.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
radicale = handleTest ./radicale.nix {};
redmine = handleTest ./redmine.nix {};
roundcube: apply code review suggestions
2018-11-28 16:33:26 +00:00
roundcube = handleTest ./roundcube.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
rspamd = handleTest ./rspamd.nix {};
rss2email module: init Also adding `system-sendmail` package for sharing the code with other modules or packages needing it.
2018-10-27 10:33:43 +01:00
rss2email = handleTest ./rss2email.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
rsyslogd = handleTest ./rsyslogd.nix {};
runInMachine = handleTest ./run-in-machine.nix {};
rxe = handleTest ./rxe.nix {};
samba = handleTest ./samba.nix {};
sddm = handleTest ./sddm.nix {};
simple = handleTest ./simple.nix {};
slim = handleTest ./slim.nix {};
slurm = handleTest ./slurm.nix {};
smokeping = handleTest ./smokeping.nix {};
snapper = handleTest ./snapper.nix {};
solr = handleTest ./solr.nix {};
nixos/sonarr: Add test for sonarr to ensure startup
2019-01-24 22:08:16 +00:00
sonarr = handleTest ./sonarr.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
strongswan-swanctl = handleTest ./strongswan-swanctl.nix {};
sudo = handleTest ./sudo.nix {};
switchTest = handleTest ./switch-test.nix {};
syncthing-relay module: init
2018-11-17 14:02:00 +00:00
syncthing-relay = handleTest ./syncthing-relay.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
systemd = handleTest ./systemd.nix {};
nixos: Add 'chroot' options to systemd.services Currently, if you want to properly chroot a systemd service, you could do it using BindReadOnlyPaths=/nix/store (which is not what I'd call "properly", because the whole store is still accessible) or use a separate derivation that gathers the runtime closure of the service you want to chroot. The former is the easier method and there is also a method directly offered by systemd, called ProtectSystem, which still leaves the whole store accessible. The latter however is a bit more involved, because you need to bind-mount each store path of the runtime closure of the service you want to chroot. This can be achieved using pkgs.closureInfo and a small derivation that packs everything into a systemd unit, which later can be added to systemd.packages. That's also what I did several times[1][2] in the past. However, this process got a bit tedious, so I decided that it would be generally useful for NixOS, so this very implementation was born. Now if you want to chroot a systemd service, all you need to do is: { systemd.services.yourservice = { description = "My Shiny Service"; wantedBy = [ "multi-user.target" ]; chroot.enable = true; serviceConfig.ExecStart = "${pkgs.myservice}/bin/myservice"; }; } If more than the dependencies for the ExecStart* and ExecStop* (which btw. also includes "script" and {pre,post}Start) need to be in the chroot, it can be specified using the chroot.packages option. By default (which uses the "full-apivfs"[3] confinement mode), a user namespace is set up as well and /proc, /sys and /dev are mounted appropriately. In addition - and by default - a /bin/sh executable is provided as well, which is useful for most programs that use the system() C library call to execute commands via shell. The shell providing /bin/sh is dash instead of the default in NixOS (which is bash), because it's way more lightweight and after all we're chrooting because we want to lower the attack surface and it should be only used for "/bin/sh -c something". Prior to submitting this here, I did a first implementation of this outside[4] of nixpkgs, which duplicated the "pathSafeName" functionality from systemd-lib.nix, just because it's only a single line. However, I decided to just re-use the one from systemd here and subsequently made it available when importing systemd-lib.nix, so that the systemd-chroot implementation also benefits from fixes to that functionality (which is now a proper function). Unfortunately, we do have a few limitations as well. The first being that DynamicUser doesn't work in conjunction with tmpfs, because it already sets up a tmpfs in a different path and simply ignores the one we define. We could probably solve this by detecting it and try to bind-mount our paths to that different path whenever DynamicUser is enabled. The second limitation/issue is that RootDirectoryStartOnly doesn't work right now, because it only affects the RootDirectory option and not the individual bind mounts or our tmpfs. It would be helpful if systemd would have a way to disable specific bind mounts as well or at least have some way to ignore failures for the bind mounts/tmpfs setup. Another quirk we do have right now is that systemd tries to create a /usr directory within the chroot, which subsequently fails. Fortunately, this is just an ugly error and not a hard failure. [1]: https://github.com/headcounter/shabitica/blob/3bb01728a0237ad5e7/default.nix#L43-L62 [2]: https://github.com/aszlig/avonc/blob/dedf29e092481a33dc/nextcloud.nix#L103-L124 [3]: The reason this is called "full-apivfs" instead of just "full" is to make room for a *real* "full" confinement mode, which is more restrictive even. [4]: https://github.com/aszlig/avonc/blob/92a20bece4df54625e/systemd-chroot.nix Signed-off-by: aszlig <aszlig@nix.build>
2019-03-10 11:21:55 +00:00
systemd-chroot = handleTest ./systemd-chroot.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
taskserver = handleTest ./taskserver.nix {};
nixos/telegraf: add test
2019-01-21 11:30:11 +00:00
telegraf = handleTest ./telegraf.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 11:30:07 +00:00
tomcat = handleTest ./tomcat.nix {};
tor = handleTest ./tor.nix {};
transmission = handleTest ./transmission.nix {};
udisks2 = handleTest ./udisks2.nix {};
upnp = handleTest ./upnp.nix {};
vault = handleTest ./vault.nix {};
virtualbox = handleTestOn ["x86_64-linux"] ./virtualbox.nix {};
wordpress = handleTest ./wordpress.nix {};
xautolock = handleTest ./xautolock.nix {};
xdg-desktop-portal = handleTest ./xdg-desktop-portal.nix {};
xfce = handleTest ./xfce.nix {};
xmonad = handleTest ./xmonad.nix {};
xrdp = handleTest ./xrdp.nix {};
xss-lock = handleTest ./xss-lock.nix {};
yabar = handleTest ./yabar.nix {};
zookeeper = handleTest ./zookeeper.nix {};
}
Copy permalink