MirrorHub/nixpkgs
0
0
Fork 0
mirror of https://github.com/NixOS/nixpkgs.git synced 2024-11-15 22:36:23 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions 2
nixpkgs/nixos/tests/all-tests.nix

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

725 lines
34 KiB
Nix
Raw Normal View History

nixos/testing: Embrace callTest My conception of its input was wrong. It is quite a useful construct, even if its name is a bit weird.
2022-06-25 12:47:50 +02:00
{ system,
pkgs,
# Projects the test configuration into a the desired value; usually
# the test runner: `config: config.test`.
callTest,
}:
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current 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
# 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:
nixos/all-tests.nix: Invoke tests based on make-test-python.nix
2022-06-25 21:26:50 +02:00
if isAttrs val
then
if hasAttr "test" val then callTest val
else mapAttrs (n: s: discoverTests s) val
else if isFunction val
then
# Tests based on make-test-python.nix will return the second lambda
# in that file, which are then forwarded to the test definition
# following the `import make-test-python.nix` expression
# (if it is a function).
discoverTests (val { inherit system pkgs; })
else val;
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current 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
handleTest = path: args:
discoverTests (import path ({ inherit system pkgs; } // args));
handleTestOn = systems: path: args:
if elem system systems then handleTest path args
else {};
nixos/nixpkgs.nix: Make independent (cherry picked from commit 62e7f0eda1c5acf0beb13a00a23f577912a6b8eb)
2021-12-03 13:04:36 +01:00
nixos/lib: Add featureFlags, use it for minimal modules
2022-01-07 01:09:46 +01:00
nixosLib = import ../lib {
# Experimental features need testing too, but there's no point in warning
# about it, so we enable the feature flag.
featureFlags.minimalModules = {};
};
nixos/nixpkgs.nix: Make independent (cherry picked from commit 62e7f0eda1c5acf0beb13a00a23f577912a6b8eb)
2021-12-03 13:04:36 +01:00
evalMinimalConfig = module: nixosLib.evalModules { modules = [ module ]; };
nixosTests: Add allDrivers for development purposes
2022-06-03 14:34:29 +02:00
nixos/all-tests.nix: Improve runTest for release.nix ... and add runTestOn.
2022-06-06 20:19:59 +02:00
inherit
(rec {
nixos/testing: Fix release.nix tests evaluation Fixes the problem introduced by 12b3066aae46a8ccc3d21f54f668a3f4be344332 which caused nixos/release.nix to return the wrong attributes, while intending to only affect nixos/lib's runTest. This also removes callTest from the test options, because callTest is only ever invoked by all-tests.nix.
2022-09-29 10:32:31 +02:00
doRunTest = arg: ((import ../lib/testing-python.nix { inherit system pkgs; }).evalTest {
imports = [ arg ];
}).config.result;
nixos/all-tests.nix: Improve runTest for release.nix ... and add runTestOn.
2022-06-06 20:19:59 +02:00
findTests = tree:
if tree?recurseForDerivations && tree.recurseForDerivations
nixos/testing: Embrace callTest My conception of its input was wrong. It is quite a useful construct, even if its name is a bit weird.
2022-06-25 12:47:50 +02:00
then
mapAttrs
(k: findTests)
(builtins.removeAttrs tree ["recurseForDerivations"])
else callTest tree;
nixos/all-tests.nix: Improve runTest for release.nix ... and add runTestOn.
2022-06-06 20:19:59 +02:00
runTest = arg: let r = doRunTest arg; in findTests r;
runTestOn = systems: arg:
if elem system systems then runTest arg
else {};
})
runTest
runTestOn
;
nixosTests.allDrivers: Move logic to all-packages.nix Bring it in line with release.nix
2022-06-06 19:24:30 +02:00
in {
nixos/testing: Add pkgs parameter This parameter is for packages to use in VMs, unlike hostPkgs.
2022-06-06 21:19:22 +02:00
_3proxy = runTest ./3proxy.nix;
nixosTests.acme: Use module system based runner
2022-06-06 23:49:59 +02:00
acme = runTest ./acme.nix;
nixosTests.adguardhome: Use module based runner
2022-06-09 17:43:22 +02:00
adguardhome = runTest ./adguardhome.nix;
nixosTests.aesmd: Use module based runner
2022-06-09 17:45:02 +02:00
aesmd = runTest ./aesmd.nix;
nixosTests.agate: Use module based runner
2022-06-09 17:46:51 +02:00
agate = runTest ./web-servers/agate.nix;
agda: Added test
2020-04-19 20:01:37 +02:00
agda = handleTest ./agda.nix {};
airsonic: add test for module
2021-05-03 17:38:02 +02:00
airsonic = handleTest ./airsonic.nix {};
nixos/terminfo: add enableAllTerminfo option Add an option to install all .terminfo packages, normally this should add no runtime bloat, if caches are used.
2021-10-05 13:33:18 +02:00
allTerminfo = handleTest ./all-terminfo.nix {};
nixos/alps: add hardening, extensible options, test
2022-11-16 17:56:44 +01:00
alps = handleTest ./alps.nix {};
nixos/amazon-init: add user-data shell script support
2021-04-18 11:19:06 +02:00
amazon-init-shell = handleTest ./amazon-init-shell.nix {};
nixos/apfs: init Add the final missing pieces for full APFS support.
2021-02-10 00:37:24 +01:00
apfs = handleTest ./apfs.nix {};
nixos/apparmor: add test for apparmorRulesFromClosure
2021-02-28 22:18:01 +01:00
apparmor = handleTest ./apparmor.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 {};
nixos/atop: Add configuration for atop services, allow to enable netatop, gpuatop, allow setuid wrapper
2021-05-14 02:11:05 +02:00
atop = handleTest ./atop.nix {};
nixos/mysql-auth: add VM-Test
2022-07-31 23:40:48 +02:00
auth-mysql = handleTest ./auth-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
avahi = handleTest ./avahi.nix {};
nixosTests.avahi: add avahi-with-resolved This allows testing avahi works with resolved being enabled, as a regression test for https://github.com/NixOS/nixpkgs/pull/99530.
2020-10-11 20:45:25 +02:00
avahi-with-resolved = handleTest ./avahi.nix { networkd = true; };
nixos/tests: add babeld
2019-10-12 01:30:55 +02:00
babeld = handleTest ./babeld.nix {};
nixos/bazarr: init
2020-05-10 12:54:09 +02:00
bazarr = handleTest ./bazarr.nix {};
linux_testing_bcachefs, bcachefs-tools: unstable-2021-07-08 → unstable-2021-11-06 bcachefs now supports snapshots so we need the latest version to use them. Additionally, it appears to build on AArch64 so I've removed the x86 requirement.
2021-11-06 22:24:16 +01:00
bcachefs = handleTestOn ["x86_64-linux" "aarch64-linux"] ./bcachefs.nix {};
nixos/beanstalkd: new service for existing package (#55953)
2019-02-22 14:10:02 +01:00
beanstalkd = handleTest ./beanstalkd.nix {};
nixosTests.bees: port to python
2019-11-24 01:10:17 +01:00
bees = handleTest ./bees.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
bind = handleTest ./bind.nix {};
nixos/tests/bird: init
2022-01-25 15:15:52 +01:00
bird = handleTest ./bird.nix {};
nixos/bitcoind: add tests
2020-07-21 13:43:32 +02:00
bitcoind = handleTest ./bitcoind.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
bittorrent = handleTest ./bittorrent.nix {};
nixos/blockbook-frontend: add tests
2020-06-23 13:09:03 +02:00
blockbook-frontend = handleTest ./blockbook-frontend.nix {};
nixos/blocky: init
2022-02-10 23:44:18 +01:00
blocky = handleTest ./blocky.nix {};
nixos/boot: test on aarch64
2021-05-25 20:13:29 +02:00
boot = handleTestOn ["x86_64-linux" "aarch64-linux"] ./boot.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
boot-stage1 = handleTest ./boot-stage1.nix {};
borgbackup = handleTest ./borgbackup.nix {};
nixos/tests/botamusique: init
2021-05-04 14:30:25 +02:00
botamusique = handleTest ./botamusique.nix {};
nixos/tests: add bpf test test bcc and bpftrace briefly
2021-12-04 02:20:26 +01:00
bpf = handleTestOn ["x86_64-linux" "aarch64-linux"] ./bpf.nix {};
breitbandmessung: init at 3.1.0
2022-01-26 14:03:05 +01:00
breitbandmessung = handleTest ./breitbandmessung.nix {};
nixos/tests: add missing tests Some tests from the `nixos/tests` folder were missing in the `all-tests.nix` file. This meant they couldn't be run from the `nixosTests` attribute set and therefore not be linked to their packages.
2022-01-23 12:11:05 +01:00
brscan5 = handleTest ./brscan5.nix {};
nixos/btrbk: add module and test
2021-05-30 14:00:00 +02:00
btrbk = handleTest ./btrbk.nix {};
nixos/btrbk: allow instances without timers This allows btrbk instances without a triggering timer by setting `onCalendar` to `null`. This is useful for manual-starting only btrbk backup settings.
2022-03-19 16:51:32 +01:00
btrbk-no-timer = handleTest ./btrbk-no-timer.nix {};
nixos/btrbk: fix ordering of subsections and refactor
2022-10-18 17:50:44 +02:00
btrbk-section-order = handleTest ./btrbk-section-order.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
buildbot = handleTest ./buildbot.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
buildkite-agents = handleTest ./buildkite-agents.nix {};
nixos/caddy: add tests (#70778)
2019-10-09 13:32:03 +02:00
caddy = handleTest ./caddy.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
cadvisor = handleTestOn ["x86_64-linux"] ./cadvisor.nix {};
nixos/tests/{sway,cage,cagebreak}: Fix the tests on aarch64-linux Since the update to wlroots 0.13 (e03dde82a74) the default VGA card isn't supported anymore and we needed to switch to virtio (qxl didn't work either). However, as it turned out "-vga virtio" (28b8cff301f) broke the test on AArch64. Luckily there's a third option that works on all three supported platforms: virtio-gpu-pci According to [0] "This device lacks VGA compatibility mode but is otherwise identical to the virtio vga device. UEFI firmware can handle this, and if your guests has drivers too you can use this instead of virtio-vga. This will reduce the attack surface (no complex VGA emulation support) and reduce the memory footprint by 8 MB (no pci memory bar for VGA compatibility). This device can be placed in a PCI Express slot." So in the end this seems like the ideal choice :) See also [1]. [0]: https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/#virtio-gpu-pci [1]: https://patches.openembedded.org/patch/164351/
2021-05-27 20:37:24 +02:00
cage = handleTest ./cage.nix {};
cagebreak = handleTest ./cagebreak.nix {};
nixos/calibre-web: init module
2021-02-23 12:23:20 +01:00
calibre-web = handleTest ./calibre-web.nix {};
cassandra: Add passthru.tests
2020-12-09 13:01:56 +01:00
cassandra_3_0 = handleTest ./cassandra.nix { testPackage = pkgs.cassandra_3_0; };
cassandra_3_11 = handleTest ./cassandra.nix { testPackage = pkgs.cassandra_3_11; };
nixos/ceph: Rename old ceph test and add new multi-node test to all-tests.nix
2019-11-01 13:12:18 +01:00
ceph-multi-node = handleTestOn ["x86_64-linux"] ./ceph-multi-node.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
ceph-single-node = handleTestOn ["x86_64-linux"] ./ceph-single-node.nix {};
nixos/tests/ceph-single-node-bluestore: init The current Ceph tests use the old method for OSDs to store data on disks, known as Filestore. This means there are no tests for the Bluestore functionality that run on install, which means that things like RocksDB being broken can slip through and break the Bluestore functionality in a subtle and difficult to debug manner. Add a test to check that Bluestore works, at least on a single node.
2021-02-14 18:59:29 +01:00
ceph-single-node-bluestore = handleTestOn ["x86_64-linux"] ./ceph-single-node-bluestore.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 {};
nixosTests.cfssl: enable on aarch64-linux
2022-09-24 09:38:37 +02:00
cfssl = handleTestOn ["aarch64-linux" "x86_64-linux"] ./cfssl.nix {};
charliecloud: 0.12 -> 0.18 (docker + ch-grow support)
2020-08-25 09:44:27 +02:00
charliecloud = handleTest ./charliecloud.nix {};
nixos/tests/chromium: Enable on aarch64-linux
2022-10-09 23:29:45 +02:00
chromium = (handleTestOn ["aarch64-linux" "x86_64-linux"] ./chromium.nix {}).stable or {};
nixos/tests/cinnamon: init
2022-09-05 09:40:17 +02:00
cinnamon = handleTest ./cinnamon.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
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 {};
nixos/cloud-init: fix hostname and resolvconf configuration - Fix hostname configuration on proxmox, which uses "hostname" in user-data instead of "local-hostname" in meta-data. - Allow setting resolv.conf through cloud-init - Add tests for new changes - Add timeouts to make tests fail faster
2022-09-30 16:08:49 +02:00
cloud-init-hostname = handleTest ./cloud-init-hostname.nix {};
cntr: only run nixosTests on aarch64/x86_64
2022-09-24 08:15:39 +02:00
cntr = handleTestOn ["aarch64-linux" "x86_64-linux"] ./cntr.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
cockroachdb = handleTestOn ["x86_64-linux"] ./cockroachdb.nix {};
nixos/collectd: add nixos test
2021-12-22 13:00:00 +01:00
collectd = handleTest ./collectd.nix {};
nixos/consul: register test
2019-11-24 15:08:53 +01:00
consul = handleTest ./consul.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
containers-bridge = handleTest ./containers-bridge.nix {};
nixos-containers: Add support for custom nixpkgs argument
2020-04-19 15:41:18 +02:00
containers-custom-pkgs.nix = handleTest ./containers-custom-pkgs.nix {};
nixos/containers: add 'ephemeral' option
2019-08-18 21:37:38 +02:00
containers-ephemeral = handleTest ./containers-ephemeral.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
containers-extra_veth = handleTest ./containers-extra_veth.nix {};
containers-hosts = handleTest ./containers-hosts.nix {};
containers-imperative = handleTest ./containers-imperative.nix {};
nixos/containers-ip: Test both ipv4 and ipv6 in the same script
2019-11-26 00:44:12 +01:00
containers-ip = handleTest ./containers-ip.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
containers-macvlans = handleTest ./containers-macvlans.nix {};
nixos/containers: allow containers with long names to create private networks Launching a container with a private network requires creating a dedicated networking interface for it; name of that interface is derived from the container name itself - e.g. a container named `foo` gets attached to an interface named `ve-foo`. An interface name can span up to IFNAMSIZ characters, which means that a container name must contain at most IFNAMSIZ - 3 - 1 = 11 characters; it's a limit that we validate using a build-time assertion. This limit has been upgraded with Linux 5.8, as it allows for an interface to contain a so-called altname, which can be much longer, while remaining treated as a first-class citizen. Since altnames have been supported natively by systemd for a while now, due diligence on our side ends with dropping the name-assertion on newer kernels. This commit closes #38509. systemd/systemd#14467 systemd/systemd#17220 https://lwn.net/Articles/794289/
2021-02-26 17:14:08 +01:00
containers-names = handleTest ./containers-names.nix {};
nixosTests.containers-nested: init
2021-02-24 14:02:57 +01:00
containers-nested = handleTest ./containers-nested.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-physical_interfaces = handleTest ./containers-physical_interfaces.nix {};
nixosTests.containers-portforward: add to all-tests.nix
2019-12-10 20:34:37 +01:00
containers-portforward = handleTest ./containers-portforward.nix {};
nixosTests.containers-reloadable: expose test This hasn't been available before in nixosTests.
2020-08-23 11:00:09 +02:00
containers-reloadable = handleTest ./containers-reloadable.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
containers-restart_networking = handleTest ./containers-restart_networking.nix {};
containers-tmpfs = handleTest ./containers-tmpfs.nix {};
nixos-container: force systemd-nspawn to use unified cgroups hierarchy
2022-10-29 22:22:57 +02:00
containers-unified-hierarchy = handleTest ./containers-unified-hierarchy.nix {};
nixos/convos: add test
2020-06-05 14:54:29 +02:00
convos = handleTest ./convos.nix {};
nixos/corerad: init
2020-01-07 17:52:32 +01:00
corerad = handleTest ./corerad.nix {};
nixos/tests/coturn: init Co-authored-by: MatthewCroughan <matt@croughan.sh>
2021-07-03 09:32:03 +02:00
coturn = handleTest ./coturn.nix {};
nixos/tests: Reenable couchdb Works just fine in current master
2019-07-24 20:48:43 +02:00
couchdb = handleTest ./couchdb.nix {};
nixosTests.cri-o: enable on aarch64-linux
2022-09-24 09:39:15 +02:00
cri-o = handleTestOn ["aarch64-linux" "x86_64-linux"] ./cri-o.nix {};
nixos/tests/custom-ca: init This is a NixOS test for the security.pki options.
2021-01-10 18:28:29 +01:00
custom-ca = handleTest ./custom-ca.nix {};
nixos/croc: init
2020-07-22 10:34:57 +02:00
croc = handleTest ./croc.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 {};
nixos: move matrix services into their category
2022-05-13 09:46:01 +02:00
dendrite = handleTest ./matrix/dendrite.nix {};
dex-oidc: add module
2021-09-20 01:43:54 +02:00
dex-oidc = handleTest ./dex-oidc.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
dhparams = handleTest ./dhparams.nix {};
installers/tools: add test for system.disableInstallerTools option This test ensures the installer tools are actually unavailable with the option set to true.
2021-09-12 08:06:34 +02:00
disable-installer-tools = handleTest ./disable-installer-tools.nix {};
nixos/discourse: Add test
2021-03-14 15:44:34 +01:00
discourse = handleTest ./discourse.nix {};
nixosTests.dnscrypt-proxy2: init This removes the old dnscrypt-proxy test.
2020-02-02 00:59:02 +01:00
dnscrypt-proxy2 = handleTestOn ["x86_64-linux"] ./dnscrypt-proxy2.nix {};
nixos/tests/dnscrypt-wrapper: init
2020-04-24 01:33:33 +02:00
dnscrypt-wrapper = handleTestOn ["x86_64-linux"] ./dnscrypt-wrapper {};
nixos/dnsdist: add test
2022-01-18 08:59:57 +01:00
dnsdist = handleTest ./dnsdist.nix {};
nixos/doas: init `doas` is a lighter alternative to `sudo` that "provide[s] 95% of the features of `sudo` with a fraction of the codebase" [1]. I prefer it to `sudo`, so I figured I would add a NixOS module in order for it to be easier to use. The module is based off of the existing `sudo` module. [1] https://github.com/Duncaen/OpenDoas
2020-04-14 05:13:36 +02:00
doas = handleTest ./doas.nix {};
nixosTests.{docker,docker-rootless}: enable on aarch64-linux
2022-09-24 09:40:42 +02:00
docker = handleTestOn ["aarch64-linux" "x86_64-linux"] ./docker.nix {};
docker-rootless = handleTestOn ["aarch64-linux" "x86_64-linux"] ./docker-rootless.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-registry = handleTest ./docker-registry.nix {};
docker-tools = handleTestOn ["x86_64-linux"] ./docker-tools.nix {};
nixosTests.docker-tools-cross: init Not everyone has a suitable remote builder set up, so the cross-compilation tests that _include_ running the result are separate. That way, most people can run the majority of the test suite without the extra setup.
2020-12-13 00:33:46 +01:00
docker-tools-cross = handleTestOn ["x86_64-linux" "aarch64-linux"] ./docker-tools-cross.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
docker-tools-overlay = handleTestOn ["x86_64-linux"] ./docker-tools-overlay.nix {};
documize-community: init at 2.2.1 Documize is an open-source alternative for wiki software like Confluence based on Go and EmberJS. This patch adds the sources for the community edition[1], for commercial their paid-plan[2] needs to be used. For commercial use a derivation that bundles the commercial package and contains a `$out/bin/documize` can be passed to `services.documize.enable`. The package compiles the Go sources, the build process also bundles the pre-built frontend from `gui/public` into the binary. The NixOS module generates a simple `systemd` unit which starts the service as a dynamic user, database and a reverse proxy won't be configured. [1] https://www.documize.com/get-started/ [2] https://www.documize.com/pricing/
2019-03-26 19:04:28 +01:00
documize = handleTest ./documize.nix {};
nixos/documentation: Add unit test
2022-07-14 11:57:37 +02:00
documentation = pkgs.callPackage ../modules/misc/documentation/test.nix { inherit nixosLib; };
nixos/tests: add missing tests Some tests from the `nixos/tests` folder were missing in the `all-tests.nix` file. This meant they couldn't be run from the `nixosTests` attribute set and therefore not be linked to their packages.
2022-01-23 12:11:05 +01:00
doh-proxy-rust = handleTest ./doh-proxy-rust.nix {};
nixos/dokuwiki: init module at 2018-04-22b
2019-12-25 23:04:55 +01:00
dokuwiki = handleTest ./dokuwiki.nix {};
nixos/tests/dolibarr: add to all-tests
2022-11-01 14:02:39 +01:00
dolibarr = handleTest ./dolibarr.nix {};
nixosTests.domination: init
2021-11-13 23:00:20 +01:00
domination = handleTest ./domination.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 {};
nixos/tests/drbd: init
2021-11-30 21:42:29 +01:00
drbd = handleTest ./drbd.nix {};
nixos/earlyoom: bring the module up to date (#163663) * nixos/earlyoom: bring the module up to date Removes deprecated option `ignoreOOMScoreAdjust`, introduces `killHook` as a replacement for `notificationsCommand`, and adds an `extraArgs` option for things not covered by the module. * nixos/earlyoom: add nixos test * nixos/earlyoom: add reportInterval Allows setting the interval for logging a memory report. Defaults to 3600 following upstream (https://github.com/rfjakob/earlyoom/blob/master/earlyoom.default#L5) to avoid flooding logs. * nixos/earlyoom: add free{Mem,Swap}KillThreshold Fixes https://github.com/NixOS/nixpkgs/issues/83504
2022-03-24 08:34:09 +01:00
earlyoom = handleTestOn ["x86_64-linux"] ./earlyoom.nix {};
nixosTests.ec2-config: Add to all-tests.nix
2020-02-13 21:31:58 +01:00
ec2-config = (handleTestOn ["x86_64-linux"] ./ec2.nix {}).boot-ec2-config or {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
ec2-nixops = (handleTestOn ["x86_64-linux"] ./ec2.nix {}).boot-ec2-nixops or {};
ecryptfs = handleTest ./ecryptfs.nix {};
nixos/pam: support fscrypt login protectors fscrypt can automatically unlock directories with the user's login password. To do this it ships a PAM module which reads the user's password and loads the respective keys into the user's kernel keyring. Significant inspiration was taken from the ecryptfs implementation.
2022-05-17 20:16:22 +02:00
fscrypt = handleTest ./fscrypt.nix {};
nixos/tests: move ejabberd and prosody test to xmpp folder
2019-06-15 11:16:28 +02:00
ejabberd = handleTest ./xmpp/ejabberd.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
elk = handleTestOn ["x86_64-linux"] ./elk.nix {};
nixos/tests: add missing tests Some tests from the `nixos/tests` folder were missing in the `all-tests.nix` file. This meant they couldn't be run from the `nixosTests` attribute set and therefore not be linked to their packages.
2022-01-23 12:11:05 +01:00
emacs-daemon = handleTest ./emacs-daemon.nix {};
nixos/endlessh: init module
2022-10-22 14:53:35 +02:00
endlessh = handleTest ./endlessh.nix {};
nixos/endlessh-go: init module
2022-09-23 22:39:38 +02:00
endlessh-go = handleTest ./endlessh-go.nix {};
nixos/engelsystem: Add test
2020-05-24 14:20:58 +02:00
engelsystem = handleTest ./engelsystem.nix {};
nixos/tests: add enlightenment desktop environment
2020-05-02 16:28:50 +02:00
enlightenment = handleTest ./enlightenment.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
env = handleTest ./env.nix {};
nixos/envoy: init
2021-08-28 04:28:27 +02:00
envoy = handleTest ./envoy.nix {};
tests/ergo: init
2020-05-24 20:39:23 +02:00
ergo = handleTest ./ergo.nix {};
nixos/tests/ergochat: init
2022-01-12 21:47:27 +01:00
ergochat = handleTest ./ergochat.nix {};
nixos/etc.nix: Make independent (cherry picked from commit 56c283e5c8dfd4d8d5daa15dfa3896beef2ac012)
2021-12-03 13:21:16 +01:00
etc = pkgs.callPackage ../modules/system/etc/test.nix { inherit evalMinimalConfig; };
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
etcd = handleTestOn ["x86_64-linux"] ./etcd.nix {};
nixos/tests: include the etcd-cluster test in all-tests.nix We seem to have had this test for quite a while, but nothing seems to reference it.
2019-07-10 01:46:21 +02:00
etcd-cluster = handleTestOn ["x86_64-linux"] ./etcd-cluster.nix {};
nixos/tests/etebase-server: init
2021-03-28 23:49:45 +02:00
etebase-server = handleTest ./etebase-server.nix {};
etesync-dav: 0.20.0 -> 0.30.6
2020-11-30 22:10:07 +01:00
etesync-dav = handleTest ./etesync-dav.nix {};
nixos/test-driver: add test for extraPythonPackages
2022-05-23 11:08:51 +02:00
extra-python-packages = handleTest ./extra-python-packages.nix {};
nixos/tests/evcc: init
2021-07-27 15:14:24 +02:00
evcc = handleTest ./evcc.nix {};
Fancontrol: add test etc from #70933 (#72065) * lm_sensors: add fancontrol module + nixos test fancontrol is a small script that checks temperature sensors and adapts fan speeds accordingly. It reads a text config file that can be auto-generated by running the pwmconfig wizard on the live system.
2019-10-29 15:06:32 +01:00
fancontrol = handleTest ./fancontrol.nix {};
fcitx: Add test (Unicode input, table input, m17n)
2020-08-26 14:58:37 +02:00
fcitx = handleTest ./fcitx {};
nixos/tests: add missing tests Some tests from the `nixos/tests` folder were missing in the `all-tests.nix` file. This meant they couldn't be run from the `nixosTests` attribute set and therefore not be linked to their packages.
2022-01-23 12:11:05 +01:00
fenics = handleTest ./fenics.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-esr-91: init at 91.0esr
2021-08-09 11:57:57 +02:00
firefox = handleTest ./firefox.nix { firefoxPackage = pkgs.firefox; };
nixos/tests: unbreak the tested job I expect it suffices that the channel only blocks on one firefox ESR test - the one for the default ESR. I didn't want to have the information about the default in two places, so either of the tests will be evaluated twice (but to the same *.drv I hope).
2021-08-10 16:15:57 +02:00
firefox-esr = handleTest ./firefox.nix { firefoxPackage = pkgs.firefox-esr; }; # used in `tested` job
firefox-esr-102-unwrapped: init at 102.0esr https://www.mozilla.org/en-US/firefox/102.0/releasenotes/
2022-06-27 12:29:15 +02:00
firefox-esr-102 = handleTest ./firefox.nix { firefoxPackage = pkgs.firefox-esr-102; };
nixos/tests: add test for firejail
2020-08-07 18:45:20 +02:00
firejail = handleTest ./firejail.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
firewall = handleTest ./firewall.nix {};
nixos/fish: generate autocompletions from man pages
2018-12-17 20:12:09 +01:00
fish = handleTest ./fish.nix {};
nixos/flannel: fix flannel nixos test, add test to all-tests.nix
2019-02-12 18:26:08 +01:00
flannel = handleTestOn ["x86_64-linux"] ./flannel.nix {};
fluentd: add simple test
2019-07-29 17:35:27 +02:00
fluentd = handleTest ./fluentd.nix {};
nixos/fluidd: init fluidd service at 1.16.2
2021-08-21 22:51:01 +02:00
fluidd = handleTest ./fluidd.nix {};
nixos.tests.fontconfig-default-fonts: init Make sure the fonts.enableDefaultFonts option works.
2019-08-29 14:02:20 +02:00
fontconfig-default-fonts = handleTest ./fontconfig-default-fonts.nix {};
nixos/freeswitch: init
2020-01-07 15:53:34 +01:00
freeswitch = handleTest ./freeswitch.nix {};
freshrss: init at 1.20.0, tests and module
2022-09-07 21:06:44 +02:00
freshrss = handleTest ./freshrss.nix {};
nixos/tests/frr: init Co-Authored-By: Martin Weinelt <hexa@darmstadt.ccc.de>
2021-06-08 21:37:03 +02:00
frr = handleTest ./frr.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
fsck = handleTest ./fsck.nix {};
ft2-clone: add nixos test
2020-07-29 19:40:38 +02:00
ft2-clone = handleTest ./ft2-clone.nix {};
mimir: switch pname to mimir
2022-06-07 12:53:15 +02:00
mimir = handleTest ./mimir.nix {};
services/garage: init
2022-09-07 22:04:27 +02:00
garage = handleTest ./garage.nix {};
nixos: add gerrit module Co-authored-by: edef <edef@edef.eu> Co-authored-by: Florian Klink <flokli@flokli.de>
2020-03-05 22:11:28 +01:00
gerrit = handleTest ./gerrit.nix {};
nixos/tests: add missing tests Some tests from the `nixos/tests` folder were missing in the `all-tests.nix` file. This meant they couldn't be run from the `nixosTests` attribute set and therefore not be linked to their packages.
2022-01-23 12:11:05 +01:00
geth = handleTest ./geth.nix {};
nixos/ghostunnel: init
2021-05-20 01:15:28 +02:00
ghostunnel = handleTest ./ghostunnel.nix {};
nixos/git-daemon: only create git user if it will be used
2020-02-26 14:05:00 +01:00
gitdaemon = handleTest ./gitdaemon.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
gitea = handleTest ./gitea.nix {};
gitlab = handleTest ./gitlab.nix {};
gitolite = handleTest ./gitolite.nix {};
gitolite: wrap gitolite-shell git wasn't found when used with services.fcgiwrap for http auth
2019-12-05 00:10:57 +01:00
gitolite-fcgiwrap = handleTest ./gitolite-fcgiwrap.nix {};
nixos/glusterfs: add test
2019-08-17 01:28:43 +02:00
glusterfs = handleTest ./glusterfs.nix {};
gnome: rename from gnome3 Since GNOME version is now 40, it no longer makes sense to use the old attribute name.
2021-05-07 23:18:14 +02:00
gnome = handleTest ./gnome.nix {};
gnome-xorg = handleTest ./gnome-xorg.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
go-neb = handleTest ./go-neb.nix {};
nixos/tests/gobgpd: init
2021-04-09 16:57:33 +02:00
gobgpd = handleTest ./gobgpd.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
gocd-agent = handleTest ./gocd-agent.nix {};
gocd-server = handleTest ./gocd-server.nix {};
nixos/gollum: add test
2022-09-10 18:01:37 +02:00
gollum = handleTest ./gollum.nix {};
nixosTests.graphene: init
2019-05-17 03:29:17 +02:00
google-oslogin = handleTest ./google-oslogin {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
gotify-server = handleTest ./gotify-server.nix {};
nixos/grafana: refactor dashboards for RFC42 This commit refactors `services.grafana.provision.dashboards` towards the RFC42 style. To preserve backwards compatibility, we have to jump through a ton of hoops, introducing esoteric type signatures and bizarre structs. The Grafana module definition should hopefully become a lot cleaner after a release cycle or two once the old configuration style is completely deprecated.
2022-09-18 11:35:07 +02:00
grafana = handleTest ./grafana {};
nixos: add grafana-agent module Easily ship logs and metrics to Grafana Cloud and other similar targets.
2022-06-15 12:11:03 +02:00
grafana-agent = handleTest ./grafana-agent.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
graphite = handleTest ./graphite.nix {};
nixos/graylog: add test Basic test which confirms new inputs can be created and that messages can be sent to a UDP-GELF input using `netcat`. This test requires 4GB of RAM to avoid issues due insufficient memory (please refer to `nixos/tests/elk.nix` for a detailed explanation of the issue) for elasticsearch. Also it's ensured that elasticsearch has an open HTTP port for communication when starting `graylog`. This is a workaround to ensure that all services are started in proper order, even in test environments with less power. However this shouldn't be implemented in the `nixos/graylog` module as this might be harmful when using elasticsearch clusters that require e.g. authentication and/or run on different servers.
2019-07-09 02:01:43 +02:00
graylog = handleTest ./graylog.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
grocy = handleTest ./grocy.nix {};
nixos/tests: add test for grub authentication
2020-06-13 12:06:26 +02:00
grub = handleTest ./grub.nix {};
nixosTests.gvisor: add test for gvisor and gvisor as a Docker runtime
2019-11-27 08:01:46 +01:00
gvisor = handleTest ./gvisor.nix {};
hadoop: add passthrough tests
2022-01-08 14:08:34 +01:00
hadoop = import ./hadoop { inherit handleTestOn; package=pkgs.hadoop; };
hadoop_3_2 = import ./hadoop { inherit handleTestOn; package=pkgs.hadoop_3_2; };
hadoop2 = import ./hadoop { inherit handleTestOn; package=pkgs.hadoop2; };
nixos/tests: add missing tests Some tests from the `nixos/tests` folder were missing in the `all-tests.nix` file. This meant they couldn't be run from the `nixosTests` attribute set and therefore not be linked to their packages.
2022-01-23 12:11:05 +01:00
haka = handleTest ./haka.nix {};
nixosTests.haste-server: init
2022-03-02 18:00:16 +01:00
haste-server = handleTest ./haste-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
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 {};
healthchecks: init at 2.2.1
2022-06-10 14:31:00 +02:00
healthchecks = handleTest ./web-apps/healthchecks.nix {};
hbase: 0.98.24 -> 2.4.11
2022-03-28 22:19:17 +02:00
hbase2 = handleTest ./hbase.nix { package=pkgs.hbase2; };
hbase: update versions and remove EoL version - remove 1.7 - 2.4.11 -> 2.4.15 - init 2.5.1 - 3.0.0-alpha-2 -> 3.0.0-alpha-3
2022-09-30 18:43:14 +02:00
hbase_2_4 = handleTest ./hbase.nix { package=pkgs.hbase_2_4; };
hbase: 0.98.24 -> 2.4.11
2022-03-28 22:19:17 +02:00
hbase3 = handleTest ./hbase.nix { package=pkgs.hbase3; };
nixos/codimd: rename to hedgedoc CodiMD was renamed to HedgeDoc. The user, group and state directory, will be named hedgedoc instead of codimd, starting with stateVersion "21.03".
2020-11-29 18:51:50 +01:00
hedgedoc = handleTest ./hedgedoc.nix {};
herbstluftwm: add NixOS test
2020-11-27 20:20:36 +01:00
herbstluftwm = handleTest ./herbstluftwm.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
installed-tests = pkgs.recurseIntoAttrs (handleTest ./installed-tests {});
nixos/invidious: add test
2021-09-07 19:44:12 +02:00
invidious = handleTest ./invidious.nix {};
nixosTests.oci-containers: enable on aarch64-linux
2022-09-24 07:58:01 +02:00
oci-containers = handleTestOn ["aarch64-linux" "x86_64-linux"] ./oci-containers.nix {};
nixosTests.odoo: init
2021-11-02 01:48:47 +01:00
odoo = handleTest ./odoo.nix {};
nixos/tests/hibernate: disable for platforms other than x86_64 Due to 9pnet_virtio bugs, /nix is no longer available after hibernation. It happens to work on x86_64, but not on other platforms.
2020-03-26 14:33:57 +01:00
# 9pnet_virtio used to mount /nix partition doesn't support
# hibernation. This test happens to work on x86_64-linux but
# not on other platforms.
hibernate = handleTestOn ["x86_64-linux"] ./hibernate.nix {};
nixos/stage-1-systemd: Implement hibernation + test
2022-04-13 13:48:20 +02:00
hibernate-systemd-stage-1 = handleTestOn ["x86_64-linux"] ./hibernate.nix { systemdStage1 = true; };
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
hitch = handleTest ./hitch {};
nixos/hledger-web: init module and test
2020-01-20 12:34:57 +01:00
hledger-web = handleTest ./hledger-web.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
hocker-fetchdocker = handleTest ./hocker-fetchdocker {};
nixos/tests: Init hockeypuck tests
2021-07-18 09:51:49 +02:00
hockeypuck = handleTest ./hockeypuck.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
home-assistant = handleTest ./home-assistant.nix {};
nixos/tests/hostname: init (check system's host name) NixOS currently has issues with setting the FQDN of a system in a way where standard tools work. In order to help with experimentation and avoid regressions, add a test that checks that the hostname is reported as the user wanted it to be. Co-authored-by: Michael Weiss <dev.primeos@gmail.com>
2020-05-12 23:48:27 +02:00
hostname = handleTest ./hostname.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
hound = handleTest ./hound.nix {};
hub: Add test
2020-12-29 17:13:26 +01:00
hub = handleTest ./git/hub.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
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 {};
python3.pkgs.ihatemoney: 4.2 -> 5.1.1
2021-10-10 14:00:00 +02:00
ihatemoney = handleTest ./ihatemoney {};
nixos/tests/all-tests.nix: Fix incron test path
2018-11-14 23:51:15 +01:00
incron = handleTest ./incron.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
influxdb = handleTest ./influxdb.nix {};
nixos/system/boot/initrd-openvpn: Add openvpn options for initrd nixos/tests/initrd-openvpn: Add test for openvpn in the initramfs The module in this commit adds new options that allows the integration of an OpenVPN client into the initrd. This can be used e.g. to remotely unlock LUKS devices. This commit also adds two tests for `boot.initrd.network.openvpn`. The first one is a basic test to validate that a failing connection does not prevent the machine from booting. The second test validates that this module actually creates a valid openvpn connection. For this, it spawns three nodes: - The client that uses boot.initrd.network.openvpn - An OpenVPN server that acts as gateway and forwards a port to the client - A node that is external to the OpenVPN network The client connects to the OpenVPN server and spawns a netcat instance that echos a value to every client. Afterwards, the external node checks if it receives this value over the forwarded port on the OpenVPN gateway.
2020-07-01 00:02:56 +02:00
initrd-network-openvpn = handleTest ./initrd-network-openvpn {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
initrd-network-ssh = handleTest ./initrd-network-ssh {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
initrdNetwork = handleTest ./initrd-network.nix {};
nixos/tests: Add test for initrd secrets lz4 compression is excluded because it doesn't work for a reason which remains unclear to me.
2020-12-12 14:39:58 +01:00
initrd-secrets = handleTest ./initrd-secrets.nix {};
nixos/input-remapper: add nixos test for input-remapper
2022-02-18 22:47:54 +01:00
input-remapper = handleTest ./input-remapper.nix {};
nixos/modules/inspircd: add simplistic module and nixos test
2021-03-22 14:32:46 +01:00
inspircd = handleTest ./inspircd.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
installer = handleTest ./installer.nix {};
nixos: Installer tests for systemd stage 1
2022-04-17 23:24:13 +02:00
installer-systemd-stage-1 = handleTest ./installer-systemd-stage-1.nix {};
nixos/invoiceplane: init module and package at 1.5.11 (#146909)
2022-01-20 14:45:35 +01:00
invoiceplane = handleTest ./invoiceplane.nix {};
nixos/iodine: add test
2020-02-02 13:00:00 +01:00
iodine = handleTest ./iodine.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
ipv6 = handleTest ./ipv6.nix {};
nixos/tests: add missing tests Some tests from the `nixos/tests` folder were missing in the `all-tests.nix` file. This meant they couldn't be run from the `nixosTests` attribute set and therefore not be linked to their packages.
2022-01-23 12:11:05 +01:00
iscsi-multipath-root = handleTest ./iscsi-multipath-root.nix {};
nixosTests.iscsi-root: init Co-authored-by: Graham Christensen <graham@floxdev.com>
2020-10-18 19:55:42 +02:00
iscsi-root = handleTest ./iscsi-root.nix {};
nixos/tests: add missing tests Some tests from the `nixos/tests` folder were missing in the `all-tests.nix` file. This meant they couldn't be run from the `nixosTests` attribute set and therefore not be linked to their packages.
2022-01-23 12:11:05 +01:00
isso = handleTest ./isso.nix {};
nixos/jackett: Add test for jackett to ensure startup
2019-01-25 07:09:36 +01:00
jackett = handleTest ./jackett.nix {};
nixos/jellyfin: add test to all-tests.nix
2019-05-01 11:57:34 +02:00
jellyfin = handleTest ./jellyfin.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
jenkins = handleTest ./jenkins.nix {};
nixos/tests: add missing tests Some tests from the `nixos/tests` folder were missing in the `all-tests.nix` file. This meant they couldn't be run from the `nixosTests` attribute set and therefore not be linked to their packages.
2022-01-23 12:11:05 +01:00
jenkins-cli = handleTest ./jenkins-cli.nix {};
nixos/jibri: add nixos test
2021-10-15 20:00:24 +02:00
jibri = handleTest ./jibri.nix {};
nixos/jirefeau: add `services.jirafeau` module Signed-off-by: David Wood <david.wood@codeplay.com>
2020-02-06 17:00:19 +01:00
jirafeau = handleTest ./jirafeau.nix {};
nixos/jitsi-meet: init
2020-03-18 04:23:15 +01:00
jitsi-meet = handleTest ./jitsi-meet.nix {};
nixos/tests/k3s: reorganize test into a subdirectory In preperation for more tests, coming soon.
2022-07-22 08:13:20 +02:00
k3s = handleTest ./k3s {};
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/kanidm: init Co-Authored-By: Martin Weinelt <mweinelt@users.noreply.github.com> Co-Authored-By: Flakebi <flakebi@t-online.de>
2022-05-05 12:09:42 +02:00
kanidm = handleTest ./kanidm.nix {};
nixos/karma: init
2022-10-10 07:16:25 +02:00
karma = handleTest ./karma.nix {};
nixos/tests/kbd-setfont-decompress: init
2021-05-30 20:37:14 +02:00
kbd-setfont-decompress = handleTest ./kbd-setfont-decompress.nix {};
nixos/tests: add kbd-update-search-paths-patch
2021-07-19 21:21:02 +02:00
kbd-update-search-paths-patch = handleTest ./kbd-update-search-paths-patch.nix {};
nixos/tests/kea: init A simple DHCPv4 test case, with borrowed structure from the systemd-networkd-dhcpserver test.
2021-07-14 00:43:17 +02:00
kea = handleTest ./kea.nix {};
nixos/keepalived: add test
2019-12-22 08:45:31 +01:00
keepalived = handleTest ./keepalived.nix {};
nixos/tests: add keepassxc Test whether KeePassXC launches correctly.
2021-02-02 12:35:46 +01:00
keepassxc = handleTest ./keepassxc.nix {};
nixos/tests/kerberos: fix evaluation
2019-01-11 05:36:51 +01:00
kerberos = handleTest ./kerberos/default.nix {};
kernel: Add tests to passthru.tests
2021-04-07 17:57:58 +02:00
kernel-generic = handleTest ./kernel-generic.nix {};
nixos/tests: add kernel-latest-ath-user-regd Test for the option `networking.wireless.athUserRegulatoryDomain` to make sure the underlying patch still applies for the latest kernel. Also see NixOS/nixpkgs#108725.
2021-01-31 14:55:53 +01:00
kernel-latest-ath-user-regd = handleTest ./kernel-latest-ath-user-regd.nix {};
nixos/keter: init Enable keter module Keter is an apploader which: 1. has the old app running on a port. 2. loads a new one, and wait for that to complete 3. switches the old with the new one once the new one finished loading. It supports more functionality but this use case is the primary one being used by supercede. Adds keter as a module to nixos. Currently keter is unusable with nix, because it relies on bundeling of a tar and uploading that to a specific folder. These expressions automate these devops tasks, with especially nixops in mind. This will work with versions above 1.8 The test seems to work. This uses a new version of keter which has good support for status code on error pages. We're using this config at production at supercede so it should be fine. Squash log: ========== mention keter in changelog Update generated release notes Always restart keter on failure This is a little bit of extra stability in case keter crashes. Which can happen under extreme conditions (DoS attacks). Update nixos/doc/manual/release-notes/rl-2205.section.md Co-authored-by: ckie <25263210+ckiee@users.noreply.github.com> Update nixos/modules/module-list.nix Co-authored-by: ckie <25263210+ckiee@users.noreply.github.com> Remove sanitization don't put domain in as a string Update nixos/tests/keter.nix Co-authored-by: ckie <25263210+ckiee@users.noreply.github.com> add jappie as module maintainer Use type path instead of two seperate options Fix generated docs added test machinery to figure out why it's failing Fix the test, use console output run nixpkgs-fmt on all modules Inline config file. This get's rid of a lot of inderection as well. Run nix format remove comment simplify executable for test delete config file add config for keter root Remove after redis clause set keter root by default to /var/lib/keter Update nixos/modules/services/web-servers/keter/default.nix Co-authored-by: ckie <25263210+ckiee@users.noreply.github.com> Update nixos/modules/services/web-servers/keter/default.nix Co-authored-by: ckie <25263210+ckiee@users.noreply.github.com> Update nixos/modules/services/web-servers/keter/default.nix Co-authored-by: ckie <25263210+ckiee@users.noreply.github.com> fix nit add newlines add default text and move description in a long description Delete rather obvious comment fix release db thing remove longDescription and put it in a comment instead change description of mkEnalbeOption explain what keter does by using the hackage synopsis set domain to keterDomain and same for executable move comment to where it's happening fix type error add formatting better comment try add seperate user for keter Revert "try add seperate user for keter" This reverts commit d3522d36c96117335bfa072e6f453406c244e940. Doing this breaks the setup set default to avoid needing cap_net_bind_service remove weird comment use example fields eleborated on process leakage Update nixos/modules/services/web-servers/keter/default.nix Co-authored-by: ckie <25263210+ckiee@users.noreply.github.com> run nixpkgs-fmt update docs Fix formatting, set keter package by default format our little nixexpr replace '' -> " where possible drop indent for multiline string make description much shorter regen docs database
2022-05-18 15:41:54 +02:00
keter = handleTest ./keter.nix {};
nixos/tests: register `kexec' test
2021-10-25 00:20:46 +02:00
kexec = handleTest ./kexec.nix {};
nixos/keycloak: Add support for MySQL and external DBs with SSL - Add support for using MySQL as an option to PostgreSQL. - Enable connecting to external DBs with SSL - Add a database port config option
2020-10-26 15:33:57 +01:00
keycloak = discoverTests (import ./keycloak.nix);
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
keymap = handleTest ./keymap.nix {};
nixos/knot: init
2019-03-13 01:12:56 +01:00
knot = handleTest ./knot.nix {};
nixos/komga: add module
2022-08-12 23:52:52 +02:00
komga = handleTest ./komga.nix {};
nixosTests.krb5: Add to all-tests.nix
2020-02-14 09:56:43 +01:00
krb5 = discoverTests (import ./krb5 {});
nixos/test/ksm: add simple test
2021-02-26 13:06:18 +01:00
ksm = handleTest ./ksm.nix {};
nixos/kthxbye: init
2022-09-25 20:46:03 +02:00
kthxbye = handleTest ./kthxbye.nix {};
kubernetes: fix flaky test and run tests as group
2021-07-30 17:16:23 +02:00
kubernetes = handleTestOn ["x86_64-linux"] ./kubernetes {};
kubo: rename from ipfs Go-IPFS was renamed to Kubo in version 0.14.0, see https://github.com/ipfs/kubo/issues/8959.
2022-07-24 20:49:05 +02:00
kubo = handleTest ./kubo.nix {};
nixosTests.ladybird: init
2022-08-16 15:03:37 +02:00
ladybird = handleTest ./ladybird.nix {};
nixos/service/languagetool: init
2022-08-16 20:33:08 +02:00
languagetool = handleTest ./languagetool.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
latestKernel.login = handleTest ./login.nix { latestKernel = true; };
leaps = handleTest ./leaps.nix {};
nixos/tests/lemmy: init Co-authored-by: Ctem <c@ctem.me> Co-authored-by: cab <cab404@mailbox.org> Co-authored-by: a-kenji <aks.kenji@protonmail.com> Co-authored-by: Shahar Dawn Or <mightyiampresence@gmail.com> Co-authored-by: Matthias Meschede <MMesch@users.noreply.github.com> Co-authored-by: Ilan Joselevich <personal@ilanjoselevich.com>
2022-09-02 11:02:51 +02:00
lemmy = handleTest ./lemmy.nix {};
nixos/libinput: add module tests
2021-11-15 12:46:20 +01:00
libinput = handleTest ./libinput.nix {};
nixos/libreddit: init module and test
2021-04-19 01:05:25 +02:00
libreddit = handleTest ./libreddit.nix {};
nixosTests.aseprite: init
2021-11-18 19:10:48 +01:00
libresprite = handleTest ./libresprite.nix {};
nixos/tests/libreswan: add test
2021-05-15 23:22:03 +02:00
libreswan = handleTest ./libreswan.nix {};
librewolf: add nixos test - support librewolf in the firefox nixos test - use the correct binary name - ensure autoplay is always on for the audio test, since librewolf disables it by default
2022-07-09 02:40:24 +02:00
librewolf = handleTest ./firefox.nix { firefoxPackage = pkgs.librewolf; };
libuiohook: init at 1.2.2
2022-07-15 22:00:28 +02:00
libuiohook = handleTest ./libuiohook.nix {};
nixos/tests/libvirtd: init
2022-08-22 05:17:06 +02:00
libvirtd = handleTest ./libvirtd.nix {};
nixos/libinput: add module tests
2021-11-15 12:46:20 +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: add lighttpd test
2022-07-24 17:04:12 +02:00
lighttpd = handleTest ./lighttpd.nix {};
nixos/limesurvey: add basic nixos test
2019-03-16 13:24:23 +01:00
limesurvey = handleTest ./limesurvey.nix {};
nixos/listmonk: init module
2022-08-30 13:15:41 +02:00
listmonk = handleTest ./listmonk.nix {};
nixos/litestream: init
2021-07-30 17:41:54 +02:00
litestream = handleTest ./litestream.nix {};
nixos/locate: Add a test
2020-11-24 02:53:21 +01:00
locate = handleTest ./locate.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
login = handleTest ./login.nix {};
nixos tests: add logrotate test make sure the service is enabled by default and works.
2022-02-11 09:49:52 +01:00
logrotate = handleTest ./logrotate.nix {};
nixos/tests: add test for loki
2019-06-27 18:11:09 +02:00
loki = handleTest ./loki.nix {};
nixos/tests/lvm2: init
2022-02-01 18:21:11 +01:00
lvm2 = handleTest ./lvm2 {};
lxd: Add tests
2020-06-08 21:33:21 +02:00
lxd = handleTest ./lxd.nix {};
lxd-nftables = handleTest ./lxd-nftables.nix {};
nixosTests.lxd-image-server: init
2021-10-20 23:39:53 +02:00
lxd-image-server = handleTest ./lxd-image-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
#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/maddy: Add module for maddy Co-authored-by: Patrick Hilhorst <git@hilhorst.be>
2021-09-10 13:08:58 +02:00
maddy = handleTest ./maddy.nix {};
nixos: add maestral tests
2022-04-01 04:41:31 +02:00
maestral = handleTest ./maestral.nix {};
nixos/tests: add magic-wormhole-mailbox-server
2020-03-30 13:30:05 +02:00
magic-wormhole-mailbox-server = handleTest ./magic-wormhole-mailbox-server.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
magnetico = handleTest ./magnetico.nix {};
nixos/mailcatcher: add nixos test
2019-03-27 12:35:24 +01:00
mailcatcher = handleTest ./mailcatcher.nix {};
mailhog: add simple test
2020-12-17 16:58:57 +01:00
mailhog = handleTest ./mailhog.nix {};
nixos/tests/man: test common functionality of both man impls
2021-09-24 20:54:08 +02:00
man = handleTest ./man.nix {};
nixos/tests/mariadb-galera: test multiple mariadb versions merge both tests and completely refactor
2021-12-08 10:47:07 +01:00
mariadb-galera = handleTest ./mysql/mariadb-galera.nix {};
nixos/tests: add mastodon test
2022-03-18 15:39:32 +01:00
mastodon = handleTestOn ["x86_64-linux" "i686-linux" "aarch64-linux"] ./web-apps/mastodon.nix {};
nixos/matomo: add test
2019-10-04 22:38:58 +02:00
matomo = handleTest ./matomo.nix {};
nixos: move matrix services into their category
2022-05-13 09:46:01 +02:00
matrix-appservice-irc = handleTest ./matrix/appservice-irc.nix {};
matrix-conduit = handleTest ./matrix/conduit.nix {};
matrix-synapse = handleTest ./matrix/synapse.nix {};
nixos/mattermost: add preferNixConfig option and tests One use case for Mattermost configuration is doing a "mostly mutable" configuration where NixOS module options take priority over Mattermost's config JSON. Add a preferNixConfig option that prefers configured Nix options over what's configured in Mattermost config if mutableConfig is set. Remove the reliance on readFile (it's flake incompatible) and use jq instead. Merge Mattermost configs together on Mattermost startup, depending on configured module options. Write tests for mutable, mostly mutable, and immutable configurations.
2021-04-12 03:29:29 +02:00
mattermost = handleTest ./mattermost.nix {};
nixos/tests: add missing tests Some tests from the `nixos/tests` folder were missing in the `all-tests.nix` file. This meant they couldn't be run from the `nixosTests` attribute set and therefore not be linked to their packages.
2022-01-23 12:11:05 +01:00
mediatomb = handleTest ./mediatomb.nix {};
nixos/mediawiki: init service to replace httpd subservice
2019-06-06 03:19:11 +02:00
mediawiki = handleTest ./mediawiki.nix {};
nixosTests.meilisearch: init (cherry picked from commit 4cc2d55f6ac2440843ef3387909dbc703f65397d)
2020-04-07 11:00:43 +02:00
meilisearch = handleTest ./meilisearch.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 {};
nixos/merecat: init
2022-10-19 10:49:57 +02:00
merecat = handleTest ./merecat.nix {};
tests: adding metabase service test
2019-08-18 09:28:16 +02:00
metabase = handleTest ./metabase.nix {};
minecraft: Add test
2020-11-28 18:42:10 +01:00
minecraft = handleTest ./minecraft.nix {};
minecraft-server: Add test
2020-11-28 18:42:46 +01:00
minecraft-server = handleTest ./minecraft-server.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
minidlna = handleTest ./minidlna.nix {};
miniflux: add service
2018-12-21 19:36:58 +01:00
miniflux = handleTest ./miniflux.nix {};
minio: add test to nixos/tests/all-tests.nix
2019-02-05 17:38:34 +01:00
minio = handleTest ./minio.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
misc = handleTest ./misc.nix {};
nixos/mjolnir: add test
2021-05-30 17:33:09 +02:00
mjolnir = handleTest ./matrix/mjolnir.nix {};
nixos/mod_perl: add test
2021-08-13 20:55:15 +02:00
mod_perl = handleTest ./mod_perl.nix {};
nixos/tests: add missing tests Some tests from the `nixos/tests` folder were missing in the `all-tests.nix` file. This meant they couldn't be run from the `nixosTests` attribute set and therefore not be linked to their packages.
2022-01-23 12:11:05 +01:00
molly-brown = handleTest ./molly-brown.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 {};
nixos/tests/moonraker: init
2022-03-22 23:35:39 +01:00
moonraker = handleTest ./moonraker.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 {};
nixos/tests: add moosefs test
2021-10-06 21:51:07 +02:00
moosefs = handleTest ./moosefs.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 {};
mpvScripts.simple-mpv-webui: 1.0.0 -> 2.1.0 This also adds a test. The current packaged version (1.0.0) is broken, it cannot find relevant files.
2021-08-01 00:44:02 +02:00
mpv = handleTest ./mpv.nix {};
nixos/tests/mtp: init Adds a fully fledged NixOS VM integration test which uses jmtpfs and gvfs to test the functionality of MTP inside of NixOS. It uses USB device emulation in QEMU to create MTP device(s) which can be tested against.
2021-11-15 06:58:12 +01:00
mtp = handleTest ./mtp.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
mumble = handleTest ./mumble.nix {};
nixos/tests: add musescore
2021-02-27 02:26:02 +01:00
musescore = handleTest ./musescore.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
munin = handleTest ./munin.nix {};
mutableUsers = handleTest ./mutable-users.nix {};
tests: add mxisd to all-tests
2019-05-18 22:18:01 +02:00
mxisd = handleTest ./mxisd.nix {};
nixos/tests: move mysql tests to subfolder
2020-04-02 22:40:55 +02:00
mysql = handleTest ./mysql/mysql.nix {};
mysql-autobackup = handleTest ./mysql/mysql-autobackup.nix {};
mysql-backup = handleTest ./mysql/mysql-backup.nix {};
mysql-replication = handleTest ./mysql/mysql-replication.nix {};
nixos/n8n: init module and test
2020-11-28 18:00:25 +01:00
n8n = handleTest ./n8n.nix {};
nagios: add nixos test
2019-12-30 13:00:00 +01:00
nagios = handleTest ./nagios.nix {};
nar-serve: init at 0.3.0 (#95420) * nar-serve: init at 0.3.0 * nixos/nar-serve: add new module Co-authored-by: zimbatm <zimbatm@zimbatm.com>
2020-11-06 18:59:51 +01:00
nar-serve = handleTest ./nar-serve.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
nat.firewall = handleTest ./nat.nix { withFirewall = true; };
nat.firewall-conntrack = handleTest ./nat.nix { withFirewall = true; withConntrackHelpers = true; };
nat.standalone = handleTest ./nat.nix { withFirewall = false; };
nixos/nats: init
2021-06-26 13:58:40 +02:00
nats = handleTest ./nats.nix {};
nixos/navidrome: init module and test Co-authored-by: aciceri <andrea.ciceri@autistici.org> Co-authored-by: nyanloutre <paul@nyanlout.re>
2020-12-05 19:11:21 +01:00
navidrome = handleTest ./navidrome.nix {};
nbd: add programs.nbd, services.nbd, and test Changes: nbd: Update nixos/modules/services/networking/nbd.nix Co-authored-by: pennae <82953136+pennae@users.noreply.github.com> nbd: Update nixos/modules/services/networking/nbd.nix Co-authored-by: pennae <82953136+pennae@users.noreply.github.com> nbd: Update nixos/tests/nbd.nix Co-authored-by: pennae <82953136+pennae@users.noreply.github.com> nbd: generalize options in nbd service nbd: harden service nbd: Update nixos/modules/services/networking/nbd.nix Co-authored-by: pennae <82953136+pennae@users.noreply.github.com> nbd: Update nixos/modules/services/networking/nbd.nix Co-authored-by: pennae <82953136+pennae@users.noreply.github.com> nbd: refactor code a bit and BindPaths automatically
2022-03-06 14:49:57 +01:00
nbd = handleTest ./nbd.nix {};
nixos/tests/ncdns: add test
2020-06-07 23:59:12 +02:00
ncdns = handleTest ./ncdns.nix {};
nixos/ndppd: register test
2019-02-03 16:47:01 +01:00
ndppd = handleTest ./ndppd.nix {};
nixos/nebula: Add nebula module and unit test to lists
2021-03-05 06:28:58 +01:00
nebula = handleTest ./nebula.nix {};
nixosTests.netbird: init
2022-08-14 18:59:15 +02:00
netbird = handleTest ./netbird.nix {};
neo4j: add neo4j test
2019-02-01 14:29:54 +01:00
neo4j = handleTest ./neo4j.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
netdata = handleTest ./netdata.nix {};
networking.networkd = handleTest ./networking.nix { networkd = true; };
networking.scripted = handleTest ./networking.nix { networkd = false; };
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
specialisation = handleTest ./specialisation.nix {};
nixos/netbox: add nixos test
2022-03-06 17:02:14 +01:00
netbox = handleTest ./web-apps/netbox.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
# TODO: put in networking.nix after the test becomes more complete
networkingProxy = handleTest ./networking-proxy.nix {};
nextcloud = handleTest ./nextcloud {};
nexus = handleTest ./nexus.nix {};
nixos/nfs: test nfs with kerberos authentication
2019-11-27 15:37:27 +01:00
# TODO: Test nfsv3 + Kerberos
nfs3 = handleTest ./nfs { version = 3; };
nfs4 = handleTest ./nfs { version = 4; };
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
nghttpx = handleTest ./nghttpx.nix {};
nginx = handleTest ./nginx.nix {};
nginx: test basic auth
2020-10-20 18:05:41 +02:00
nginx-auth = handleTest ./nginx-auth.nix {};
nginx: Clear Last-Modified if ETag is from store This is what I've suspected a while ago[1]: > Heads-up everyone: After testing this in a few production instances, > it seems that some browsers still get cache hits for new store paths > (and changed contents) for some reason. I highly suspect that it might > be due to the last-modified header (as mentioned in [2]). > > Going to test this with last-modified disabled for a little while and > if this is the case I think we should improve that patch by disabling > last-modified if serving from a store path. Much earlier[2] when I reviewed the patch, I wrote this: > Other than that, it looks good to me. > > However, I'm not sure what we should do with Last-Modified header. > From RFC 2616, section 13.3.4: > > - If both an entity tag and a Last-Modified value have been > provided by the origin server, SHOULD use both validators in > cache-conditional requests. This allows both HTTP/1.0 and > HTTP/1.1 caches to respond appropriately. > > I'm a bit nervous about the SHOULD here, as user agents in the wild > could possibly just use Last-Modified and use the cached content > instead. Unfortunately, I didn't pursue this any further back then because @pbogdan noted[3] the following: > Hmm, could they (assuming they are conforming): > > * If an entity tag has been provided by the origin server, MUST > use that entity tag in any cache-conditional request (using If- > Match or If-None-Match). Since running with this patch in some deployments, I found that both Firefox and Chrome/Chromium do NOT re-validate against the ETag if the Last-Modified header is still the same. So I wrote a small NixOS VM test with Geckodriver to have a test case which is closer to the real world and I indeed was able to reproduce this. Whether this is actually a bug in Chrome or Firefox is an entirely different issue and even IF it is the fault of the browsers and it is fixed at some point, we'd still need to handle this for older browser versions. Apart from clearing the header, I also recreated the patch by using a plain "git diff" with a small description on top. This should make it easier for future authors to work on that patch. [1]: https://github.com/NixOS/nixpkgs/pull/48337#issuecomment-495072764 [2]: https://github.com/NixOS/nixpkgs/pull/48337#issuecomment-451644084 [3]: https://github.com/NixOS/nixpkgs/pull/48337#issuecomment-451646135 Signed-off-by: aszlig <aszlig@nix.build>
2019-12-30 14:06:00 +01:00
nginx-etag = handleTest ./nginx-etag.nix {};
nixos/tests: add nginx-http3 test
2022-04-18 12:22:39 +02:00
nginx-http3 = handleTest ./nginx-http3.nix {};
nixos/tests/nginx-modsecurity: init
2022-02-15 00:10:37 +01:00
nginx-modsecurity = handleTest ./nginx-modsecurity.nix {};
nginxModules.njs: init at 0.7.8
2022-09-18 14:54:04 +02:00
nginx-njs = handleTest ./nginx-njs.nix {};
nginx: Fix ETag patch to ignore realpath(3) error While our ETag patch works pretty fine if it comes to serving data off store paths, it unfortunately broke something that might be a bit more common, namely when using regexes to extract path components of location directives for example. Recently, @devhell has reported a bug with a nginx location directive like this: location ~^/\~([a-z0-9_]+)(/.*)?$" { alias /home/$1/public_html$2; } While this might look harmless at first glance, it does however cause issues with our ETag patch. The alias directive gets broken up by nginx like this: *2 http script copy: "/home/" *2 http script capture: "foo" *2 http script copy: "/public_html/" *2 http script capture: "bar.txt" In our patch however, we use realpath(3) to get the canonicalised path from ngx_http_core_loc_conf_s.root, which returns the *configured* value from the root or alias directive. So in the example above, realpath(3) boils down to the following syscalls: lstat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat("/home/$1", 0x7ffd08da6f60) = -1 ENOENT (No such file or directory) During my review[1] of the initial patch, I didn't actually notice that what we're doing here is returning NGX_ERROR if the realpath(3) call fails, which in turn causes an HTTP 500 error. Since our patch actually made the canonicalisation (and thus additional syscalls) necessary, we really shouldn't introduce an additional error so let's - at least for now - silently skip return value if realpath(3) has failed. However since we're using the unaltered root from the config we have another issue, consider this root: /nix/store/...-abcde/$1 Calling realpath(3) on this path will fail (except if there's a file called "$1" of course), so even this fix is not enough because it results in the ETag not being set to the store path hash. While this is very ugly and we should fix this very soon, it's not as serious as getting HTTP 500 errors for serving static files. I added a small NixOS VM test, which uses the example above as a regression test. It seems that my memory is failing these days, since apparently I *knew* about this issue since digging for existing issues in nixpkgs, I found this similar pull request which I even reviewed: https://github.com/NixOS/nixpkgs/pull/66532 However, since the comments weren't addressed and the author hasn't responded to the pull request, I decided to keep this very commit and do a follow-up pull request. [1]: https://github.com/NixOS/nixpkgs/pull/48337 Signed-off-by: aszlig <aszlig@nix.build> Reported-by: @devhell Acked-by: @7c6f434c Acked-by: @yorickvP Merges: https://github.com/NixOS/nixpkgs/pull/80671 Fixes: https://github.com/NixOS/nixpkgs/pull/66532
2020-02-20 20:43:42 +01:00
nginx-pubhtml = handleTest ./nginx-pubhtml.nix {};
nixos/tests: add nginx-sandbox test
2020-04-23 21:00:27 +02:00
nginx-sandbox = handleTestOn ["x86_64-linux"] ./nginx-sandbox.nix {};
nixos/tests: add nginx-sso basic functionality test
2018-12-28 11:41:52 +01:00
nginx-sso = handleTest ./nginx-sso.nix {};
nixos/nginx: ensure all variants have a basic level of testing
2020-06-02 07:01:03 +02:00
nginx-variants = handleTest ./nginx-variants.nix {};
nixos/tests: add nifi test
2022-04-10 19:41:30 +02:00
nifi = handleTestOn ["x86_64-linux"] ./web-apps/nifi.nix {};
nixos/nitter: init module and test
2021-07-26 12:00:05 +02:00
nitter = handleTest ./nitter.nix {};
tests/nix-ld: fix invocation
2022-04-11 20:51:29 +02:00
nix-ld = handleTest ./nix-ld.nix {};
nixos/tests: fix nix-serve path nixos/tests: rename nix-ssh-serve to nix-serve-ssh nixos/tests/nix-serve-ssh: add --experimental-features nixos-serve: add nix-serve-ssh to passthru.tests
2021-12-03 17:19:42 +01:00
nix-serve = handleTest ./nix-serve.nix {};
nix-serve-ssh = handleTest ./nix-serve-ssh.nix {};
nixopsUnstable: Add test
2021-10-18 00:38:58 +02:00
nixops = handleTest ./nixops/default.nix {};
nixos-generate-config: enable overriding configuration.nix
2019-08-07 18:04:18 +02:00
nixos-generate-config = handleTest ./nixos-generate-config.nix {};
nixos/nixpkgs.nix: Make independent (cherry picked from commit 62e7f0eda1c5acf0beb13a00a23f577912a6b8eb)
2021-12-03 13:04:36 +01:00
nixpkgs = pkgs.callPackage ../modules/misc/nixpkgs/test.nix { inherit evalMinimalConfig; };
nixos/node-red: add test
2021-07-28 12:42:26 +02:00
node-red = handleTest ./node-red.nix {};
nixos/nomad: add extraSettingsFiles option to nomad service (#109761)
2021-01-23 23:52:19 +01:00
nomad = handleTest ./nomad.nix {};
nixos/tests: add non-default-filesystems test
2022-06-22 04:10:44 +02:00
non-default-filesystems = handleTest ./non-default-filesystems.nix {};
nixos: add sample test for noto fonts
2022-01-22 03:06:13 +01:00
noto-fonts = handleTest ./noto-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
novacomd = handleTestOn ["x86_64-linux"] ./novacomd.nix {};
nixosTests.nscd: init, move DynamicUser test into there nixosTests.systemd is quite heavy, it requires a full graphical system, which is quite a big of a rebuild if the only thing you want to test is whether dynamic users work. This is now moved to an `nscd` test, which tests various NSS lookups, making extra sure that the nscd path is tested, not the fallback path (by hiding /etc/nsswitch.conf and /etc/hosts for getent). nixosTests.resolv is removed. It didn't check for reverse lookups, didn't catch nscd breaking halfway in between, and also had an ambiguous reverse lookup - 192.0.2.1 could either reverse lookup to host-ipv4.example.net, or host-dual.example.net.
2022-10-07 11:40:33 +02:00
nscd = handleTest ./nscd.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
nsd = handleTest ./nsd.nix {};
nixos/ntfy-sh: init
2022-09-01 14:36:19 +02:00
ntfy-sh = handleTest ./ntfy-sh.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 {};
nixos/nzbhydra2: init
2020-10-04 16:06:53 +02:00
nzbhydra2 = handleTest ./nzbhydra2.nix {};
oh-my-zsh: Add test
2020-11-05 02:37:50 +01:00
oh-my-zsh = handleTest ./oh-my-zsh.nix {};
nixos/ombi: add test for ombi to ensure startup
2021-03-29 16:51:05 +02:00
ombi = handleTest ./ombi.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 {};
nixos/tests/openresty-lua: test openresty with lua related to #140655
2021-10-07 05:36:02 +02:00
openresty-lua = handleTest ./openresty-lua.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
opensmtpd = handleTest ./opensmtpd.nix {};
opensmtpd-filter-rspamd: init at 0.1.7 (#122823)
2021-05-19 22:37:49 +02:00
opensmtpd-rspamd = handleTest ./opensmtpd-rspamd.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
openssh = handleTest ./openssh.nix {};
Rename `novaImage` to `openstackImage` People don't necessary know `nova` is related to Openstack (it is a component of Openstack). So, it is more explicit to call it `openstackImage`.
2019-01-28 15:09:48 +01:00
openstack-image-metadata = (handleTestOn ["x86_64-linux"] ./openstack-image.nix {}).metadata or {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
openstack-image-userdata = (handleTestOn ["x86_64-linux"] ./openstack-image.nix {}).userdata or {};
nixos/opentabletdriver: add tests
2021-01-08 17:48:00 +01:00
opentabletdriver = handleTest ./opentabletdriver.nix {};
nixos/owncast: init owncast service
2021-09-23 10:48:29 +02:00
owncast = handleTest ./owncast.nix {};
nixosTests.image-contents: init
2020-12-20 21:18:54 +01:00
image-contents = handleTest ./image-contents.nix {};
nixos/orangefs: add test
2019-08-21 00:27:14 +02:00
orangefs = handleTest ./orangefs.nix {};
mention the os-prober test in pkgs.os-prober.passthru.tests
2019-06-09 20:26:05 +02:00
os-prober = handleTestOn ["x86_64-linux"] ./os-prober.nix {};
nixos/tests: add osrm-backend test
2019-01-05 13:13:10 +01:00
osrm-backend = handleTest ./osrm-backend.nix {};
nixos/overlayfs: add test
2019-01-23 10:19:23 +01:00
overlayfs = handleTest ./overlayfs.nix {};
nixos/tests/pacemaker: init
2022-03-08 02:46:26 +01:00
pacemaker = handleTest ./pacemaker.nix {};
nixos/packagekit: add test
2019-04-24 10:45:29 +02:00
packagekit = handleTest ./packagekit.nix {};
tests: Move all PAM tests into a separate directory As per <https://github.com/NixOS/nixpkgs/pull/146467#issuecomment-972743535>.
2021-11-27 09:04:28 +01:00
pam-file-contents = handleTest ./pam/pam-file-contents.nix {};
pam-oath-login = handleTest ./pam/pam-oath-login.nix {};
pam-u2f = handleTest ./pam/pam-u2f.nix {};
nixos/pam: add support for pam-ussh pam-ussh allows authorizing using an SSH certificate stored in your SSH agent, in a similar manner to pam-ssh-agent-auth, but for certificates rather than raw public keys.
2022-03-13 18:20:23 +01:00
pam-ussh = handleTest ./pam/pam-ussh.nix {};
pass-secret-service: unstable-2020-04-12 -> unstable-2022-03-21 * Update to the latest upstream version of pass-secret-service that includes systemd service files. * Add patch to fix use of a function that has been removed from the Python Cryptography library in NixOS 22.05 * Install systemd service files in the Nix package. * Add NixOS test to ensure the D-Bus API activates the service unit. * Add myself as a maintainer to the package and NixOS test. * Use checkTarget instead of equivalent custom checkPhase.
2022-04-16 07:18:57 +02:00
pass-secret-service = handleTest ./pass-secret-service.nix {};
nixos/patroni: only run tests on x86_64-linux etcd doesn't support other architectures and refuses to start
2022-11-23 18:53:04 +01:00
patroni = handleTestOn ["x86_64-linux"] ./patroni.nix {};
nixos/pantalaimon: add test Co-authored-by: sumnerevans <me@sumnerevans.com>
2021-05-30 17:32:41 +02:00
pantalaimon = handleTest ./matrix/pantalaimon.nix {};
nixos/tests/all-tests.nix: add pantheon
2019-01-24 23:33:05 +01:00
pantheon = handleTest ./pantheon.nix {};
nixos/paperless-ng: rename to `paperless`, use `paperless-ngx` package Use this opportunity to rename `paperless-(ng)-server` to `paperless-scheduler`. This follows the naming scheme in the paperless repo and docs.
2022-04-12 17:48:53 +02:00
paperless = handleTest ./paperless.nix {};
nixos/parsedmarc: Add test
2021-06-02 18:19:37 +02:00
parsedmarc = handleTest ./parsedmarc {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
pdns-recursor = handleTest ./pdns-recursor.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
peerflix = handleTest ./peerflix.nix {};
nixos/tests: add peertube test
2021-05-31 13:23:06 +02:00
peertube = handleTestOn ["x86_64-linux"] ./web-apps/peertube.nix {};
pgadmin4: init at 6.3 Signed-off-by: Florian Brandes <florian.brandes@posteo.de>
2021-07-02 14:22:12 +02:00
pgadmin4 = handleTest ./pgadmin4.nix {};
tests/pgadmin4-standalone: add
2022-02-23 15:16:23 +01:00
pgadmin4-standalone = handleTest ./pgadmin4-standalone.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
pgjwt = handleTest ./pgjwt.nix {};
pgmanage = handleTest ./pgmanage.nix {};
nixos/tests/phosh: init
2022-08-02 21:34:37 +02:00
phosh = handleTest ./phosh.nix {};
nixos/php: Add tests for phpfpm This test checks that we evaluate PHP properly and that certain extensions are actually loaded.
2020-03-30 22:07:05 +02:00
php = handleTest ./php {};
nixos/tests/php: Select the right versions of the tests depending on version
2021-02-28 21:16:08 +01:00
php80 = handleTest ./php { php = pkgs.php80; };
php81: init at 8.1.1
2021-11-25 21:38:19 +01:00
php81 = handleTest ./php { php = pkgs.php81; };
php82: init at 8.2.0rc6
2022-11-13 21:14:38 +01:00
php82 = handleTest ./php { php = pkgs.php82; };
nixos/tests: add phlactery
2022-06-28 21:17:38 +02:00
phylactery = handleTest ./web-apps/phylactery.nix {};
nixos/tests: add missing tests Some tests from the `nixos/tests` folder were missing in the `all-tests.nix` file. This meant they couldn't be run from the `nixosTests` attribute set and therefore not be linked to their packages.
2022-01-23 12:11:05 +01:00
pict-rs = handleTest ./pict-rs.nix {};
nixos/tests/pinnwand: init
2020-06-03 23:12:06 +02:00
pinnwand = handleTest ./pinnwand.nix {};
nixos/plasma5: add very basic plasma-bigscreen module
2022-09-17 15:02:37 +02:00
plasma-bigscreen = handleTest ./plasma-bigscreen.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
plasma5 = handleTest ./plasma5.nix {};
nixosTest/plasma5-systemd-start: init
2021-10-31 21:34:10 +01:00
plasma5-systemd-start = handleTest ./plasma5-systemd-start.nix {};
plausible: init at 1.3.0
2021-05-21 23:15:23 +02:00
plausible = handleTest ./plausible.nix {};
nixos/please: init module Co-authored-by: Cole Helbling <cole.e.helbling@outlook.com>
2022-09-29 23:12:29 +02:00
please = handleTest ./please.nix {};
nixos/pleroma: add NixOS VM test.
2020-11-08 15:10:14 +01:00
pleroma = handleTestOn [ "x86_64-linux" "aarch64-linux" ] ./pleroma.nix {};
nixos/tests: new test for plikd
2020-11-13 15:00:34 +01:00
plikd = handleTest ./plikd.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
plotinus = handleTest ./plotinus.nix {};
nixos/tests/podgrab: init
2021-04-14 19:15:41 +02:00
podgrab = handleTest ./podgrab.nix {};
nixosTests.podman*: enable on aarch64-linux
2022-09-24 07:58:15 +02:00
podman = handleTestOn ["aarch64-linux" "x86_64-linux"] ./podman/default.nix {};
podman-dnsname = handleTestOn ["aarch64-linux" "x86_64-linux"] ./podman/dnsname.nix {};
podman-tls-ghostunnel = handleTestOn ["aarch64-linux" "x86_64-linux"] ./podman/tls-ghostunnel.nix {};
nixos/polaris: init
2022-06-17 20:04:54 +02:00
polaris = handleTest ./polaris.nix {};
nixos/tests/pomerium: init
2021-01-08 04:03:00 +01:00
pomerium = handleTestOn ["x86_64-linux"] ./pomerium.nix {};
postfix: Add submissions option for postfix and test (#91691) RFC 8314 suggests, for end user submission of mails, SMTP over TLS on port 465 should be used. Closes #91690
2020-07-06 03:37:56 +02:00
postfix = handleTest ./postfix.nix {};
postfix-raise-smtpd-tls-security-level = handleTest ./postfix-raise-smtpd-tls-security-level.nix {};
postfixadmin: init at 3.3.9
2021-05-19 06:34:03 +02:00
postfixadmin = handleTest ./postfixadmin.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
postgis = handleTest ./postgis.nix {};
postgresql = handleTest ./postgresql.nix {};
nixos/postgresql-wal-receiver: add module (#63799)
2019-08-11 19:09:42 +02:00
postgresql-wal-receiver = handleTest ./postgresql-wal-receiver.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
powerdns = handleTest ./powerdns.nix {};
powerdns-admin: fix and add module - Add the migrations directory to the package - Add postgres support to the package - Add a service for powerdns-admin Co-authored-by: Zhaofeng Li <hello@zhaofeng.li>
2021-12-17 10:33:40 +01:00
powerdns-admin = handleTest ./powerdns-admin.nix {};
nixosTests.power-profiles-daemon: add to all-tests.nix This was forgotten in the inital PR.
2021-10-29 06:15:27 +02:00
power-profiles-daemon = handleTest ./power-profiles-daemon.nix {};
nixos/tests/pppd: init This test creates a PPPoE link between two machines, and verifies that the machines can ping each other.
2019-10-15 06:26:54 +02:00
pppd = handleTest ./pppd.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
predictable-interface-names = handleTest ./predictable-interface-names.nix {};
printing = handleTest ./printing.nix {};
privacyidea module: init
2020-04-21 13:37:00 +02:00
privacyidea = handleTest ./privacyidea.nix {};
nixos/tests/privoxy: add test
2021-03-03 17:18:09 +01:00
privoxy = handleTest ./privoxy.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
prometheus = handleTest ./prometheus.nix {};
prometheus-exporters = handleTest ./prometheus-exporters.nix {};
nixos/tests: move ejabberd and prosody test to xmpp folder
2019-06-15 11:16:28 +02:00
prosody = handleTest ./xmpp/prosody.nix {};
nixos/tests/prosody: return prosody-mysql test
2022-02-18 20:19:31 +01:00
prosody-mysql = 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 {};
nixos/tests/prowlarr: init
2021-10-10 17:54:22 +02:00
prowlarr = handleTest ./prowlarr.nix {};
pt2-clone: add nixos test
2020-07-29 19:00:33 +02:00
pt2-clone = handleTest ./pt2-clone.nix {};
pykms: switch to maintained fork, fix PYTHONPATH, add test I have read the full diff[0] between the previous owner and the new maintained fork that I'm switching to, and could not find any suspicious code. The new fork includes fixes that are otherwise crashing as of Python 3.10. This commit also fixes the PYTHONPATH which prevents the client from starting. This commit also adds a test that the client can successfully query the server, testing the two components at once. [0] https://github.com/SystemRage/py-kms/compare/master...Py-KMS-Organization:master
2022-06-27 00:20:04 +02:00
pykms = handleTest ./pykms.nix {};
nixos/public-inbox: add tests
2021-12-01 11:06:18 +01:00
public-inbox = handleTest ./public-inbox.nix {};
nixosTests.pulseAudio: init
2021-11-30 14:51:06 +01:00
pulseaudio = discoverTests (import ./pulseaudio.nix);
nixos/qemu-vm: add option to use a non-standard BIOS I'd like to change the default on x86 platforms to qboot at some point, since it saves a fair bit of startup time.
2020-05-22 05:15:32 +02:00
qboot = handleTestOn ["x86_64-linux" "i686-linux"] ./qboot.nix {};
nixos/quorum: init
2020-03-22 17:26:55 +01:00
quorum = handleTest ./quorum.nix {};
nixos-tests: bring back quake3 test
2022-09-21 22:26:03 +02:00
quake3 = handleTest ./quake3.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
rabbitmq = handleTest ./rabbitmq.nix {};
nixos/radarr: Add test for radarr to ensure startup
2019-01-24 23:09:21 +01:00
radarr = handleTest ./radarr.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
radicale = handleTest ./radicale.nix {};
nixosTests.rasdaemon: init module test and passthru test in the package
2021-02-02 01:39:50 +01:00
rasdaemon = handleTest ./rasdaemon.nix {};
nixos/redis: add test
2019-08-31 20:17:33 +02:00
redis = handleTest ./redis.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
redmine = handleTest ./redmine.nix {};
nixos/switch-to-configuration: Allow activation scripts to restart units The primary use case is tools like sops-nix and agenix to restart units when secrets change. There's probably other reasons to restart units as well and a nice thing to have in general.
2021-09-08 21:02:28 +02:00
restartByActivationScript = handleTest ./restart-by-activation-script.nix {};
nixos/tests/restic.nix: add test
2020-01-30 22:31:52 +01:00
restic = handleTest ./restic.nix {};
nixos/retroarch: add RetroArch as a desktop session
2022-02-05 00:50:11 +01:00
retroarch = handleTest ./retroarch.nix {};
nixos/tests/robustirc-bridge: init
2020-08-30 18:31:54 +02:00
robustirc-bridge = handleTest ./robustirc-bridge.nix {};
roundcube: apply code review suggestions
2018-11-28 17:33:26 +01:00
roundcube = handleTest ./roundcube.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
rspamd = handleTest ./rspamd.nix {};
rss2email module: init Also adding `system-sendmail` package for sharing the code with other modules or packages needing it.
2018-10-27 11:33:43 +02:00
rss2email = handleTest ./rss2email.nix {};
nixos/tests: add missing tests Some tests from the `nixos/tests` folder were missing in the `all-tests.nix` file. This meant they couldn't be run from the `nixosTests` attribute set and therefore not be linked to their packages.
2022-01-23 12:11:05 +01:00
rstudio-server = handleTest ./rstudio-server.nix {};
rsyncd = handleTest ./rsyncd.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 {};
rxe = handleTest ./rxe.nix {};
sabnzbd: add simple test
2021-09-21 13:38:22 +02:00
sabnzbd = handleTest ./sabnzbd.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
samba = handleTest ./samba.nix {};
nixos/tests/samba-wsdd: add check WSD Discovery
2020-11-23 15:13:22 +01:00
samba-wsdd = handleTest ./samba-wsdd.nix {};
nixos/sanoid, nixos/syncoid: init module and test
2019-10-27 04:37:30 +01:00
sanoid = handleTest ./sanoid.nix {};
nixos/schleuder: init module and accompanying test Co-Authored-By: Martin Weinelt <hexa@darmstadt.ccc.de> Co-Authored-By: Cole Helbling <cole.helbling@determinate.systems>
2022-05-31 17:27:54 +02:00
schleuder = handleTest ./schleuder.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
sddm = handleTest ./sddm.nix {};
nixosTests.seafile: link the committed test It succeeds for me. Apparently this line was forgotten in PR #119719.
2021-11-07 09:05:36 +01:00
seafile = handleTest ./seafile.nix {};
nixos/tests: add searx test
2020-11-02 01:34:53 +01:00
searx = handleTest ./searx.nix {};
nixos/service-runner.nix: Allow quotes in commands + test
2020-02-28 12:17:01 +01:00
service-runner = handleTest ./service-runner.nix {};
sfxr-qt: add nixos test
2022-03-20 22:39:04 +01:00
sfxr-qt = handleTest ./sfxr-qt.nix {};
shadow: Add test
2020-12-23 19:28:30 +01:00
shadow = handleTest ./shadow.nix {};
nixos/shadowsocks: add test without plugin
2020-09-09 00:15:59 +02:00
shadowsocks = handleTest ./shadowsocks {};
shattered-pixel-dungeon: add nixos test
2020-08-09 15:20:17 +02:00
shattered-pixel-dungeon = handleTest ./shattered-pixel-dungeon.nix {};
nixos/tests: add shiori to all-tests.nix
2019-11-08 18:17:08 +01:00
shiori = handleTest ./shiori.nix {};
nixosTests.signal-desktop: add test
2019-05-23 00:50:51 +02:00
signal-desktop = handleTest ./signal-desktop.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
simple = handleTest ./simple.nix {};
slurm = handleTest ./slurm.nix {};
smokeping = handleTest ./smokeping.nix {};
nixos/tests: add snapcast Checks - if all configured ports are listened on - if all pipes for multiple streams get set up - if rpc interaction is possible
2020-07-28 14:47:36 +02:00
snapcast = handleTest ./snapcast.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
snapper = handleTest ./snapper.nix {};
nixos/tests: add missing tests Some tests from the `nixos/tests` folder were missing in the `all-tests.nix` file. This meant they couldn't be run from the `nixosTests` attribute set and therefore not be linked to their packages.
2022-01-23 12:11:05 +01:00
soapui = handleTest ./soapui.nix {};
nixosTests.sogo: init test
2020-05-12 18:32:39 +02:00
sogo = handleTest ./sogo.nix {};
nixos/solanum: init
2021-05-20 22:03:39 +02:00
solanum = handleTest ./solanum.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
solr = handleTest ./solr.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
sonarr = handleTest ./sonarr.nix {};
nixos/sourcehut: update test
2021-08-28 19:46:05 +02:00
sourcehut = handleTest ./sourcehut.nix {};
nixos/spacecookie: add service module and test
2019-05-24 21:17:51 +02:00
spacecookie = handleTest ./spacecookie.nix {};
spark: init 3.2.1 and test on aarch64-linux
2022-02-08 14:59:23 +01:00
spark = handleTestOn [ "x86_64-linux" "aarch64-linux" ] ./spark {};
sqlite3-to-mysql: init at 1.4.16 Signed-off-by: Florian Brandes <florian.brandes@posteo.de>
2022-11-13 20:13:15 +01:00
sqlite3-to-mysql = handleTest ./sqlite3-to-mysql.nix {};
nixos: add test for sslh
2020-01-18 13:00:00 +01:00
sslh = handleTest ./sslh.nix {};
nixos/sssd: fix the module 'system.nssModules' was not set correctly fix #91242
2020-08-24 15:55:22 +02:00
sssd = handleTestOn ["x86_64-linux"] ./sssd.nix {};
nixos/tests/sssd-ldap: init
2020-09-01 07:03:20 +02:00
sssd-ldap = handleTestOn ["x86_64-linux"] ./sssd-ldap.nix {};
nixos/starship: add a test
2021-12-24 12:24:29 +01:00
starship = handleTest ./starship.nix {};
nixos/tests: add step-ca test
2021-11-12 21:37:11 +01:00
step-ca = handleTestOn ["x86_64-linux"] ./step-ca.nix {};
nixos/stratis: add test for simple usecases
2022-09-12 09:18:11 +02:00
stratis = handleTest ./stratis {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current 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 {};
nixos/tests/stunnel: init
2022-02-22 23:08:43 +01:00
stunnel = handleTest ./stunnel.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
sudo = handleTest ./sudo.nix {};
nixos/tests: add swap-partition test
2022-06-22 04:11:23 +02:00
swap-partition = handleTest ./swap-partition.nix {};
nixos/tests/{sway,cage,cagebreak}: Fix the tests on aarch64-linux Since the update to wlroots 0.13 (e03dde82a74) the default VGA card isn't supported anymore and we needed to switch to virtio (qxl didn't work either). However, as it turned out "-vga virtio" (28b8cff301f) broke the test on AArch64. Luckily there's a third option that works on all three supported platforms: virtio-gpu-pci According to [0] "This device lacks VGA compatibility mode but is otherwise identical to the virtio vga device. UEFI firmware can handle this, and if your guests has drivers too you can use this instead of virtio-vga. This will reduce the attack surface (no complex VGA emulation support) and reduce the memory footprint by 8 MB (no pci memory bar for VGA compatibility). This device can be placed in a PCI Express slot." So in the end this seems like the ideal choice :) See also [1]. [0]: https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/#virtio-gpu-pci [1]: https://patches.openembedded.org/patch/164351/
2021-05-27 20:37:24 +02:00
sway = handleTest ./sway.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
switchTest = handleTest ./switch-test.nix {};
nixos/sympa: init module
2019-07-06 20:56:30 +02:00
sympa = handleTest ./sympa.nix {};
nixos/tests: Add test for syncthing
2020-07-23 09:13:26 +02:00
syncthing = handleTest ./syncthing.nix {};
nixos/syncthing: add options for declarative device/folder config
2019-04-21 23:05:07 +02:00
syncthing-init = handleTest ./syncthing-init.nix {};
syncthing-relay module: init
2018-11-17 15:02:00 +01:00
syncthing-relay = handleTest ./syncthing-relay.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
systemd = handleTest ./systemd.nix {};
nixos/tests: add systemd-analyze test
2019-11-25 00:03:55 +01:00
systemd-analyze = handleTest ./systemd-analyze.nix {};
nixosTests.systemd-binfmt: init This adds a simple test running GNU Hello cross-compiled for armv7l and aarch64 inside a x86_64 VM with configured binfmt. We already build the cross toolchains in other invocations, and building hello itself is small.
2020-05-18 11:16:56 +02:00
systemd-binfmt = handleTestOn ["x86_64-linux"] ./systemd-binfmt.nix {};
nixos/systemd-boot: run test on aarch64
2020-06-14 05:57:52 +02:00
systemd-boot = handleTest ./systemd-boot.nix {};
systemd: enable `BPF_FRAMEWORK` by default (`withLibBPF=true`) So far, we have been building Systemd without `BPF_FRAMEWORK`. As a result, some Systemd features like `RestrictNetworkInterfaces=` cannot work. To make things worse, Systemd doesn't even complain when using a feature which requires `+BPF_FRAMEWORK`; yet, the option has no effect: # systemctl --version | grep -o "\-BPF_FRAMEWORK" -BPF_FRAMEWORK # systemd-run -t -p RestrictNetworkInterfaces="lo" ping -c 1 8.8.8.8 This commit enables `BPF_FRAMEWORK` by default. This is in line with other distros (e.g., Fedora). Also note that BPF does not support stack protector: https://lkml.org/lkml/2020/2/21/1000. To that end, I added a small `CFLAGS` patch to the BPF building to keep using stack protector as a default. I also added an appropriate NixOS test.
2022-08-21 12:22:16 +02:00
systemd-bpf = handleTest ./systemd-bpf.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-coredump: improve disabled state The systemd-coredump module required systemd to be built with withCoredump=true, even if the module was disabled. - allow systemd to be missing systemd-coredump if the module is disabled - switch to mkDefault for the sysctl config to allow user overrides when the module is disabled - add nixos tests for both the enabled and disabled cases
2022-08-01 18:44:29 +02:00
systemd-coredump = handleTest ./systemd-coredump.nix {};
nixos/tests/systemd-cryptenroll: add basic TPM2 test
2021-10-04 12:54:13 +02:00
systemd-cryptenroll = handleTest ./systemd-cryptenroll.nix {};
nixos: add functions and documentation for escaping systemd Exec* directives it's really easy to accidentally write the wrong systemd Exec* directive, ones that works most of the time but fails when users include systemd metacharacters in arguments that are interpolated into an Exec* directive. add a few functions analogous to escapeShellArg{,s} and some documentation on how and when to use them.
2022-01-09 08:46:55 +01:00
systemd-escaping = handleTest ./systemd-escaping.nix {};
nixos/btrfs: Add systemd stage 1 support
2022-04-17 14:55:48 +02:00
systemd-initrd-btrfs-raid = handleTest ./systemd-initrd-btrfs-raid.nix {};
nixos/tests/systemd-initrd-luks-fido2: init
2022-10-03 19:10:03 +02:00
systemd-initrd-luks-fido2 = handleTest ./systemd-initrd-luks-fido2.nix {};
nixos/stage-1-systemd: Add a test for LUKS keyfiles
2022-04-13 23:27:58 +02:00
systemd-initrd-luks-keyfile = handleTest ./systemd-initrd-luks-keyfile.nix {};
nixos/stage-1-systemd: Add LUKS w/ password support
2022-04-13 20:45:29 +02:00
systemd-initrd-luks-password = handleTest ./systemd-initrd-luks-password.nix {};
nixos/tests/systemd-initrd-luks-tpm2: init
2022-09-23 23:47:05 +02:00
systemd-initrd-luks-tpm2 = handleTest ./systemd-initrd-luks-tpm2.nix {};
nixos/tests/systemd-initrd-modprobe: init
2022-10-05 02:37:51 +02:00
systemd-initrd-modprobe = handleTest ./systemd-initrd-modprobe.nix {};
nixos/systemd: Properly shut down the system
2022-04-15 12:23:02 +02:00
systemd-initrd-shutdown = handleTest ./systemd-shutdown.nix { systemdStage1 = true; };
systemd-initrd: Basic test case
2022-03-20 21:11:32 +01:00
systemd-initrd-simple = handleTest ./systemd-initrd-simple.nix {};
nixos/stage-1-init: Merge mdraid module into swraid
2022-04-15 17:28:41 +02:00
systemd-initrd-swraid = handleTest ./systemd-initrd-swraid.nix {};
nixos.tests.systemd-journal: add basic systemd-journal-gatewayd test This test allows to ensure the systemd-journal-gatewayd service is responding correcly when the NixOS option `enableHttpGateway` is set. The test has not been added into the main systemd test because a graphical stack is not required (and rebuilding the graphical stack on systemd change is huge).
2020-11-01 18:48:40 +01:00
systemd-journal = handleTest ./systemd-journal.nix {};
nixos: Switch to default systemd-nspawn behaviour
2022-02-17 22:07:05 +01:00
systemd-machinectl = handleTest ./systemd-machinectl.nix {};
nixos/networkd: test routingPolicyRules with a nixos vm test
2020-02-29 19:34:48 +01:00
systemd-networkd = handleTest ./systemd-networkd.nix {};
systemd-networkd: add DHCPServer test
2019-11-16 12:13:51 +01:00
systemd-networkd-dhcpserver = handleTest ./systemd-networkd-dhcpserver.nix {};
nixos/networkd: add `dhcpServerStaticLeaseConfig` option Add `systemd.network.networks.*.dhcpServerStaticLeaseConfig` to allow for configuring static DHCP leases through the `[DHCPServerStaticLease]` section. See systemd.network(5) of systemd 249 for details. Also adds the NixOS test `systemd-networkd-dhcpserver-static-lease` to test the assignment of static leases.
2021-11-30 09:57:15 +01:00
systemd-networkd-dhcpserver-static-leases = handleTest ./systemd-networkd-dhcpserver-static-leases.nix {};
nixos/tests: add systemd-networkd-ipv6-prefix-delegation This is a follow-up to the PR #82026 that contains the promised tests. In this test I am testing if we can properly propagate prefixes received via DHCPv6 PD with the networkd options in our module system. The comments in the test should be sufficient to follow the idea and what is going on.
2020-05-01 15:12:19 +02:00
systemd-networkd-ipv6-prefix-delegation = handleTest ./systemd-networkd-ipv6-prefix-delegation.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
systemd-networkd-vrf = handleTest ./systemd-networkd-vrf.nix {};
systemd-no-tainted: init as regression test
2022-10-04 18:19:38 +02:00
systemd-no-tainted = handleTest ./systemd-no-tainted.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 {};
nixos/systemd-oomd: Add a new module + test
2022-04-21 19:54:50 +02:00
systemd-oomd = handleTest ./systemd-oomd.nix {};
nixos/tests: init systemd-portabled Please enter the commit message for your changes. Lines starting
2022-09-29 12:57:18 +02:00
systemd-portabled = handleTest ./systemd-portabled.nix {};
nixos/systemd: Properly shut down the system
2022-04-15 12:23:02 +02:00
systemd-shutdown = handleTest ./systemd-shutdown.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
systemd-timesyncd = handleTest ./systemd-timesyncd.nix {};
nixos/systemd: Allow creation of unit directories This patch allows creation of files like /etc/systemd/system/user-.slice.d/limits.conf with systemd.units."user-.slice.d/limits.conf" = { text = '' [Slice] CPUAccounting=yes CPUQuota=50% ''; }; which previously threw an error Also renames the systemd-unit-path test to sytsemd-misc, and extends it to test that `systemd.units` can handle directories. In this case we make sure that resource limits specified in user slices apply.
2021-08-11 20:28:30 +02:00
systemd-misc = handleTest ./systemd-misc.nix {};
nixos/tandoor-recipes: add test
2022-09-17 16:36:39 +02:00
tandoor-recipes = handleTest ./tandoor-recipes.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/tests: add missing tests Some tests from the `nixos/tests` folder were missing in the `all-tests.nix` file. This meant they couldn't be run from the `nixosTests` attribute set and therefore not be linked to their packages.
2022-01-23 12:11:05 +01:00
teeworlds = handleTest ./teeworlds.nix {};
nixos/telegraf: add test
2019-01-21 12:30:11 +01:00
telegraf = handleTest ./telegraf.nix {};
nixos/tests/teleport: init
2022-01-10 13:46:47 +01:00
teleport = handleTest ./teleport.nix {};
nixos/thelounge: add test
2022-01-11 03:29:04 +01:00
thelounge = handleTest ./thelounge.nix {};
nixos/tests: add integration tests for terminal emulators
2020-11-13 19:41:14 +01:00
terminal-emulators = handleTest ./terminal-emulators.nix {};
nixos/tiddlywiki: init Service that runs TiddlyWiki nodejs server
2019-04-29 22:46:00 +02:00
tiddlywiki = handleTest ./tiddlywiki.nix {};
tigervnc, tightvnc: add basic tests Co-Authored-By: Ingo Blechschmidt <iblech@web.de>
2020-04-13 05:56:20 +02:00
tigervnc = handleTest ./tigervnc.nix {};
nixos/tests/timezone: port to python
2019-12-02 23:28:53 +01:00
timezone = handleTest ./timezone.nix {};
nixos/tests/tinc: init with simple test
2020-12-06 16:05:21 +01:00
tinc = handleTest ./tinc {};
nixos: add test for tinydns
2019-05-16 23:42:02 +02:00
tinydns = handleTest ./tinydns.nix {};
nixos/tests/tinywl: init This adds a very minimalistic (in terms of functionality and dependencies) test for wlroots, Wayland, and related packages. The Sway test covers more functionality and packages (e.g. XWayland) but this test has tree advantages: - Less dependencies: Much fewer rebuilds are required when testing core changes that need to go through staging. - Testing wlroots updates: The Sway package isn't immediately updated after a new wlroots version is released and a lot of other packages depend on wlroots as well. - Determining whether a bug only affects Sway or wlroots/TinyWL as well.
2021-12-28 21:32:26 +01:00
tinywl = handleTest ./tinywl.nix {};
nixos/tmate-ssh-server: init module (#192270) * nixos/tmate-ssh-server: init module Co-authored-by: Aaron Andersen <aaron@fosslib.net>
2022-10-05 18:34:30 +02:00
tmate-ssh-server = handleTest ./tmate-ssh-server.nix { };
nixos/tomcat: add basic test case using the example app
2022-03-13 14:31:43 +01:00
tomcat = handleTest ./tomcat.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 {};
nixosTests.traefik: enable on aarch64-linux
2022-09-24 09:43:38 +02:00
traefik = handleTestOn ["aarch64-linux" "x86_64-linux"] ./traefik.nix {};
nixos/tests/trafficserver: init
2021-04-09 18:48:51 +02:00
trafficserver = handleTest ./trafficserver.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
transmission = handleTest ./transmission.nix {};
tracee: 0.7.0 -> 0.8.3 Also simplified the package since after #176152 the tracee build process can now pass in a -target of bpf without weird overrides
2022-10-02 12:43:54 +02:00
# tracee requires bpf
tracee = handleTestOn ["x86_64-linux"] ./tracee.nix {};
tests: adding trezord
2019-08-16 17:00:07 +02:00
trezord = handleTest ./trezord.nix {};
nixos/trickster: add test
2019-11-01 11:03:23 +01:00
trickster = handleTest ./trickster.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
trilium-server = handleTestOn ["x86_64-linux"] ./trilium-server.nix {};
tsm-client: add test derivation and a module test The tsm-client needs a tsm-server to do anything useful. Without a server, automated tests can just check diagnostic outputs for plausibility. The commit at hand adds two tests: 1. The command line interface `dsmc` is called, then it is verified that the program does * report the correct client version, * find its configuration file, * report a connection error. 2. To check the GUI (and the tsm-client nixos module), we add a vm test which uses the module to install `tsm-client-withGui`. To verify that the GUI's basic functionality is present, we skip over all connection failure related error messages and open the "Connection Information" dialog from the main application window. This dialog presents the node name and the client version; both are verified by the test. Note: Our `tsm-client` build recipe consists of two packages: The "unwrapped" package and the final package. This commit puts the unwrapped one into the final package's `passthru` so that tests can access the original version string that is needed to check the client version reported by the application.
2021-12-18 09:21:57 +01:00
tsm-client-gui = handleTest ./tsm-client-gui.nix {};
pythonPackages.txredisapi: Add unit test
2021-06-24 23:34:03 +02:00
txredisapi = handleTest ./txredisapi.nix {};
nixosTests.tuptime: init test
2020-03-24 23:45:49 +01:00
tuptime = handleTest ./tuptime.nix {};
turbovnc: Add programs.turbovnc, add test for headless software OpenGL
2021-03-14 06:13:41 +01:00
turbovnc-headless-server = handleTest ./turbovnc-headless-server.nix {};
tuxguitar: 125945 (#131028) * tuxguitar: Ensure that tuxguitar is launched with java 8 comtabilbe jre and libraries as greate java version is not supported * tuxguitar: Added test to verify application starts without problems * tuxguitar: 1.5.2 -> 1.5.4
2021-07-23 16:02:20 +02:00
tuxguitar = handleTest ./tuxguitar.nix {};
nixos/test/ucarp: init
2021-06-13 22:00:25 +02:00
ucarp = handleTest ./ucarp.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
udisks2 = handleTest ./udisks2.nix {};
ucg: init at 20190225
2020-11-30 00:00:38 +01:00
unbound = handleTest ./unbound.nix {};
unifi: Add NixOS tests
2021-12-18 00:55:13 +01:00
unifi = handleTest ./unifi.nix {};
nixos/tests: add unit-php test
2020-04-16 22:08:00 +02:00
unit-php = handleTest ./web-servers/unit-php.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
upnp = handleTest ./upnp.nix {};
nixos/tests/uptermd: init
2022-03-17 17:57:23 +01:00
uptermd = handleTest ./uptermd.nix {};
nixos/uptime-kuma: init module
2022-09-23 07:04:23 +02:00
uptime-kuma = handleTest ./uptime-kuma.nix {};
nixos/tests/usbguard: init
2021-01-16 23:15:52 +01:00
usbguard = handleTest ./usbguard.nix {};
nixos/activation-script: Add a test
2021-02-15 23:40:54 +01:00
user-activation-scripts = handleTest ./user-activation-scripts.nix {};
nixos/users-group: Add 'homeMode' option.
2022-04-10 21:06:19 +02:00
user-home-mode = handleTest ./user-home-mode.nix {};
nixos: add test for uwsgi
2019-05-27 23:03:22 +02:00
uwsgi = handleTest ./uwsgi.nix {};
nixos/tests/v2ray: init
2020-06-12 10:12:51 +02:00
v2ray = handleTest ./v2ray.nix {};
nixos/tests/varnish: init
2022-09-27 21:22:21 +02:00
varnish60 = handleTest ./varnish.nix { package = pkgs.varnish60; };
varnish72 = handleTest ./varnish.nix { package = pkgs.varnish72; };
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
vault = handleTest ./vault.nix {};
nixos/vault: add option to start in dev mode. (#180114) * nixos/vault: add option to start in dev mode. This is not only useful for nixos tests i.e. when testing vault agent setups but also when playing around with vault in local setups. In our tests we can now make use of this option to test more vault features. i.e. adding this feature has uncovered the need for a `StateDirectory`. * Update nixos/modules/services/security/vault.nix Co-authored-by: Robert Hensing <roberth@users.noreply.github.com> Co-authored-by: Jonas Chevalier <zimbatm@zimbatm.com> Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2022-07-05 10:54:11 +02:00
vault-dev = handleTest ./vault-dev.nix {};
nixosTests.vault-postgresql: init
2021-01-04 17:54:03 +01:00
vault-postgresql = handleTest ./vault-postgresql.nix {};
vaultwarden: update to 1.22.1, rename from bitwarden_rs I tried to make this as non-breaking as possible, but it will still break things slightly for people expecting certain file names in the packages themselves.
2021-07-01 11:14:51 +02:00
vaultwarden = handleTest ./vaultwarden.nix {};
nixos/vector: add module
2020-11-30 08:22:08 +01:00
vector = handleTest ./vector.nix {};
nixosTests.vengi-tools: init
2021-11-21 18:09:17 +01:00
vengi-tools = handleTest ./vengi-tools.nix {};
victoriametrics: add module, tests
2020-01-19 18:55:56 +01:00
victoriametrics = handleTest ./victoriametrics.nix {};
nixos/vikunja: add nixos test
2021-06-26 14:26:17 +02:00
vikunja = handleTest ./vikunja.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
virtualbox = handleTestOn ["x86_64-linux"] ./virtualbox.nix {};
nixos/tests/vscodium{,-wayland}: merge tests
2021-11-19 21:21:20 +01:00
vscodium = discoverTests (import ./vscodium.nix);
vsftpd: enable seccomp (#158974) * vsftpd: enable seccomp * nixos/tests/vsftpd: add basic test * vsftpd: add test to passthru
2022-03-01 04:03:47 +01:00
vsftpd = handleTest ./vsftpd.nix {};
nixosTests.warzone2100: init
2022-11-24 20:46:05 +01:00
warzone2100 = handleTest ./warzone2100.nix {};
tests/wasabibackend: init
2020-06-18 14:19:13 +02:00
wasabibackend = handleTest ./wasabibackend.nix {};
wiki-js: init at 2.5.191
2021-03-18 12:33:40 +01:00
wiki-js = handleTest ./wiki-js.nix {};
nixos/tests: add missing tests Some tests from the `nixos/tests` folder were missing in the `all-tests.nix` file. This meant they couldn't be run from the `nixosTests` attribute set and therefore not be linked to their packages.
2022-01-23 12:11:05 +01:00
wine = handleTest ./wine.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 {};
nixos/nix-daemon: Add enable option Don't worry, it's is true by default. But I think this is important to have because NixOS indeed shouldn't need Nix at run time when the installation is not being modified, and now we can verify that. NixOS images that cannot "self-modify" are a legitamate use-case that this supports more minimally. One should be able to e.g. do a sshfs mount and use `nixos-install` to modify them remotely, or just discard them and build fresh ones if they are run VMs or something. The next step would be to make generations optional, allowing just baking `/etc` and friends rather than using activation scripts. But that's more involved so I'm leaving it out.
2021-04-24 23:02:15 +02:00
without-nix = handleTest ./without-nix.nix {};
wmderland: init at 2020-07-17
2021-01-27 15:44:27 +01:00
wmderland = handleTest ./wmderland.nix {};
nixos/tests/wpa_supplicant: init
2021-09-24 13:25:16 +02:00
wpa_supplicant = handleTest ./wpa_supplicant.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 {};
nixos/security/wrappers: add test This is a small smoke test of each piece (setuid, setgid, caps) of wrappers' functionality. It doesn't try to check for combinations of functionalities or anything more complicated.
2022-11-05 12:38:11 +01:00
wrappers = handleTest ./wrappers.nix {};
nixos/writefreely: init
2022-06-26 07:08:43 +02:00
writefreely = handleTest ./web-apps/writefreely.nix {};
nixosTests.xandikos: init
2019-12-14 01:17:49 +01:00
xandikos = handleTest ./xandikos.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
xautolock = handleTest ./xautolock.nix {};
xfce = handleTest ./xfce.nix {};
xmonad = handleTest ./xmonad.nix {};
nixos/desktop-manager/none: add option to run XDG autostart files `fcitx5` and `service.earlyoom` rely on use XDG autostart files to start. But for X session with only window manager and no desktop manager (`none` is used), no one can start them. This options is added to run these autostart files for sessions without desktop manager to make other services just work.
2021-06-18 15:10:26 +02:00
xmonad-xdg-autostart = handleTest ./xmonad-xdg-autostart.nix {};
nixos/xpadneo: add sanity test
2022-09-21 01:39:13 +02:00
xpadneo = handleTest ./xpadneo.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
xrdp = handleTest ./xrdp.nix {};
xss-lock = handleTest ./xss-lock.nix {};
xterm: Add test
2020-11-17 04:13:13 +01:00
xterm = handleTest ./xterm.nix {};
xxh: added tests
2022-01-01 22:16:13 +01:00
xxh = handleTest ./xxh.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
yabar = handleTest ./yabar.nix {};
nixos/yggdrasil: add service
2019-06-27 17:56:10 +02:00
yggdrasil = handleTest ./yggdrasil.nix {};
Zammad: more fixes
2022-02-16 06:49:51 +01:00
zammad = handleTest ./zammad.nix {};
zeronet-conservancy: add nixos test
2022-06-10 14:54:16 +02:00
zeronet-conservancy = handleTest ./zeronet-conservancy.nix {};
nixosTests.zfs: Add to all-tests.nix
2020-02-03 18:33:26 +01:00
zfs = handleTest ./zfs.nix {};
nixos/zigbee2mqtt: add test to all-tests.nix
2020-08-03 12:43:13 +02:00
zigbee2mqtt = handleTest ./zigbee2mqtt.nix {};
nixos/zoneminder: add minimal test
2020-04-11 19:28:52 +02:00
zoneminder = handleTest ./zoneminder.nix {};
tests: split into a separate `all-tests.nix` file This will make the list much easier to re-use, eg. for `nixosTests` The drawback is that this approaches makes the ``` nix-build release.nix -A tests.opensmtpd.x86_64-linux ``` command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs` once for each architecture, instead of just having the hardcoded list of tests that allowed to say “ok just evaluate for x86_64-linux”. On the other hand, complete evaluation of `release.nix` should be much faster because we no longer import `nixpkgs` for each test: testing with the following command went from 30s to 18s, and that's just for a few tests. ``` time nix-instantiate --eval --strict nixos/release.nix -A tests.nat ``` I initially wanted to test on the whole `release.nix`, but there are too many broken tests and it takes too long to eval them all, especially compared to the fact that the current implementation breaks some setup. Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds like an overall win.
2018-11-11 12:30:07 +01:00
zookeeper = handleTest ./zookeeper.nix {};
nixos/zrepl: note about systemd unit, add snapshot test Signed-off-by: Matt Layher <mdlayher@gmail.com>
2022-03-29 20:44:07 +02:00
zrepl = handleTest ./zrepl.nix {};
nixos/zoneminder: add minimal test
2020-04-11 19:28:52 +02:00
zsh-history = handleTest ./zsh-history.nix {};
nixosTests.allDrivers: Move logic to all-packages.nix Bring it in line with release.nix
2022-06-06 19:24:30 +02:00
}
Reference in a new issue Copy permalink