| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
nixos-rebuild deploys /etc/nixos/flake.nix instead of NIX_PATH if that
file exists, so deploying anything but a flake fails on such targets.
Without writeDeploy's flake parameter, nixos-rebuild gets --no-flake if
/etc/nixos/flake.nix exists on the build target. nixos-rebuild versions
predating flakes neither know --no-flake nor look for that file, so they
don't get it.
The deploy VM test covers targets with and without that file.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Populate never removes what it delivered for sources that aren't
configured anymore. For flake and flake-input sources, that keeps their
garbage collector roots, so what they delivered never gets collected.
With prune, populate removes everything from the target directory that
isn't a source, except .populate, after syncing the sources. It also
removes the roots in .populate/flake-inputs of names that aren't flake or
flake-input sources, and uploads left behind by interrupted runs.
Pruning is opt-in, because the target directory may contain other things
worth keeping, or be shared by deployments with different sources.
writeDeploy, writeTest, and writeCommand pass prune on to populate.
A feature scenario deploys sources, deploys fewer without pruning, then
with pruning, and checks that the removed sources' entries and roots are
gone, while the remaining sources and .populate stay.
|
|
|
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.
|
