aboutsummaryrefslogtreecommitdiffstats
path: root/tests/default.nix
Commit message (Collapse)AuthorAgeFilesLines
* tests: add edge cases of flakestv2 days1-2/+3
| | | | | | | | | | | | | | | | | A new test, edge-cases, covers paths that work but have no scenario yet: a flake given by an indirect reference, which the target fetches by its locked reference; a remote flake in a subdirectory; a flake in a subdirectory drawing inputs from sources; a dirty Git work tree; a flake whose lock file needs updating; drawing inputs from a source that isn't a directory; nested names of missing inputs; several sources sharing one flake; and an input locked to a path that the target has. The deploying machine gets a registry entry for the indirect reference. Resolving it fails if the global registry can't be downloaded, which it can't in the VM, and disabling the global registry with flake-registry needs flakes, so the deploying machine enables them, like any deploying machine using indirect references does. The target doesn't, so checks for flake support on targets still mean something.
* krops writeDeploy: pass --use-remote-sudo only with a separate build targettv2 days1-2/+3
| | | | | | | | | | | | For targets using sudo, writeDeploy runs nixos-rebuild on the target via sudo, so --use-remote-sudo has no effect there. It only matters when nixos-rebuild runs on a separate build target and activates the system on the target, so writeDeploy passes it only then. A new VM test, deploy, runs writeDeploy with a stand-in for nixos-rebuild, which records the user it runs as, NIX_PATH, and its arguments, for deploying flakes and other sources, with and without a separate build target, to every kind of target.
* tests: add NixOS VM tests for populatetv2 days1-0/+24
tests/default.nix provides one VM test per source type, and one for features spanning sources. Each test runs scenarios from tests/scenarios.nix, which cover every combination of a source type's options, deployed to the deploying machine itself, to a remote target as root, and to a remote target using sudo. A scenario prepares the target directory, deploys, checks the result, and deploys and checks again. Scenarios expecting populate to fail check its error message, or check at evaluation time if populate is expected not to evaluate. The deploying machine creates fixtures using tests/fixtures.sh and serves them via HTTP and git daemon, so flakes can be fetched on the target without further network access. Checks evaluate delivered flakes without network access to the fixtures after collecting garbage, so they verify that the delivered store paths are complete and rooted.