| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
An override below an input drawn from a source that has a generated
flake itself got placed on that generated flake, which has no such
input, so Nix ignored it with a warning. Generated flakes have their
source as input of the same name, so the override goes below that.
An edge case overrides an input of a source with a generated flake.
|
| |
|
|
|
|
|
|
|
|
| |
Populate stopped the ssh master at the end of its script, which a failure
skips. The master then stays for an hour, with its control socket gone
along with populate's temporary directory. Populate stops it on exit
now, before removing that directory.
An edge case checks that no master remains after a failing and after a
succeeding deploy.
|
| |
|
|
|
|
|
|
| |
nix-store --add-root only replaces symlinks pointing into the store, so a
symlink pointing elsewhere at the target path, e.g. one a symlink source
left there, made delivering a flake fail. Populate removes such links.
An edge case switches a symlink source to a flake source.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
rsync follows a symlink at the target path, so a source switching from the
flake or flake-input type to file, pass, passage, or pipe got written into
the store path the link points to, and one switching from the symlink
type into what that link points to, e.g. another source. Populate
removes a symlink at the target path before syncing with rsync.
The roots in .populate/flake-inputs/<name> of a source that is neither a
flake nor a flake-input source anymore get removed as well.
An edge case switches a flake source to a file source.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A flake-input source delivers an input as its own flake, which
evaluating it uses with its own lock file. Populate, however, took the
input's inputs from the parent flake's lock file: on the target, by
walking the lock file, and on the deploying machine, from the parent's
nix flake archive. That had several consequences:
- An empty follows path, which removes an input, or two inputs following
each other made the walk loop forever.
- Copying left out inputs that follow other inputs, and rejected names
through them, e.g. dep/inner where dep's inner follows another input.
- Inputs given by relative paths, e.g. path:./lib, which have no lock
entry of their own to fetch, broke fetching on the target and
flake-input sources.
- Where the parent overrides an input's inputs, the input's own lock file
pins other versions than the delivered ones.
Populate now resolves the name through the parent's lock file, follows
included and guarded against cycles, to what to fetch: a locked
reference, or the flake itself, which inputs given by relative paths are
part of. It fetches that, on the deploying machine or on the target, and
then the inputs the input's own lock file pins, using nix flake archive.
An input without a lock file comes without its inputs.
New edge cases cover lock files with empty and cyclic follows, names
through follows, the delivered closure, and relative path inputs.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Populate ends by stopping the ssh master, which fails if no source
started one, e.g. for local targets, which populate doesn't reach via
ssh. Populate then exits with ssh's exit status, though all sources got
delivered. Populate now checks for a master first.
|
| |
|
|
|
|
|
|
| |
Depending on the version of Nix, flake references and lock entries name
the subdirectory containing a flake either as attribute dir or as query
parameter dir of their URL. fetchTree supports neither, so populate
looks for both: it takes the subdirectory from either, from the locked
or the original reference, and removes both before fetching.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With fetchOnTarget, the target fetches the flake's inputs using the
arguments recorded in the lock file, like it does for flake-input
sources. The flake itself has no lock entry, so the target fetches it
by its locked reference, unless that refers to the deploying machine,
e.g. a path or a Git work tree. Then the flake's tree gets transferred
using rsync and added to the target's store using nix-store --add-fixed,
which yields the same store path as on the deploying machine, because
flake store paths are content-addressed by their NAR hash. Adding paths
like this needs neither signatures nor a trusted user, so this works for
targets using sudo. The transfer gets skipped if the target's store has
the flake already, and populate fails if the added path differs from
the expected one.
rsync' gets a filterFiles option, so the flake's tree gets transferred
without applying .rsync-filter files, which would change it.
|
| |
|
|
|
|
|
| |
The flake-input source type delivers an input of a flake, as recorded in the
flake's lock file, and the flake source type delivers the flake itself.
fetchOnTarget belongs to flake-input, because only a locked input can be
fetched on the target.
|
| |
|
|
|
| |
The flake parameter names a source. If the source draws inputs from other
sources, its generated flake gets deployed.
|
| |
|
|
|
|
| |
With flake set, nixos-rebuild deploys that flake from the build target's
source directory, with flakes enabled for the command. The deployment fails
with an error message unless Nix on the build target supports flakes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
For each source that draws inputs from other sources, populate generates a
flake in .populate/flakes/<name>, which re-exports the outputs of the
source's flake with those inputs drawn from the other sources. The source
itself stays as it is, so NIX_PATH still refers to it.
Generated flakes refer to each other's generated flakes, so a source's own
declarations apply wherever it gets drawn from, and get generated in
dependency order. Evaluation fails for sources drawing inputs from missing
sources, from themselves, or from each other. Generated flakes get locked on
every run, and get removed once their sources no longer draw inputs from
other sources.
|
| |
|
|
|
|
|
|
|
|
| |
With fetchOnTarget, the target fetches the input and its own inputs itself,
using fetchTree with the arguments recorded in the flake's lock file. Only
nix flake metadata runs on the deploying machine, so the inputs get
downloaded once, by the target. This needs Nix with flake support on the
target, which populate checks before fetching.
Because nothing gets copied, this also works for targets using sudo.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Deliver a flake, or one of its locked inputs, to the target: archive the
flake locally, copy the selected input together with its own inputs into the
target's store, and link it at the target path, registered as garbage
collector root. The result can be used in NIX_PATH as well as by flakes
evaluated on the target, without network access.
nix copy runs with a separate ssh wrapper without the control socket, because
Nix waits for its LocalCommand, which may not run over a multiplexed
connection.
|
| |
|
|
|
|
|
| |
Each job and the ssh wrapper run as separate scripts, which only see
TMPDIR if it's exported. Without TMPDIR in the caller's environment,
jobs fail, and the ssh wrapper's control socket ends up at the root
directory.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Set TMPDIR to a fresh, private top-level temporary directory, and run each job
in a separate subdirectory beneath it.
TMPDIR remains shared across all jobs, allowing reuse of resources like ssh
control sockets.
|
| | |
|
| |
|
|
| |
Generate a reproducible output to transmit it only if it has changed.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
this fixes folders with symlinks not getting updated if the symlinked
file is in another subfolder of the pass repo
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
| |
This is the expected behavior.
The SSH config is also implicitly used for other SSH-related settings.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
In the case we need sudo for the remote target, the flag
`--use-remote-sudo` must be passed if the target's ssh user is not root.
If target's ssh user is root, it doesn't hurt to use sudo.
|
| | |
|
| | |
|
| | |
|