This adds basic advisory locking such that two Nixinate deployments do
not run the activation script at the same time, both for local and
remote. The default timeout is 60 seconds, and is currently
unconfigurable.
In the previous attempt to add this feature, I had forgotten to add the
new tests to tests/default.nix, which meant I believed the feature
worked when it did not. Additionally, real world testing shows that if
the path does not exist on the remote already, that nix build --store
will not work and will throw the following error: 'path '/nix/store/foo'
is required, but there is no substituter that can build it' To fix this,
I've decided to use nix copy --derivation and then nix-store --realise
on the remote. A lot of refactoring is needed to make this codebase
presentable anyway, so this hack is fine for now, though it is
admittedly an unclean implementation.
A hermetic remote rebuild is when Nixinate sends a specific Nix binary
to the remote first, then uses it when activating a system closure,
rather than using the Nix that is already on the remote. This is
defaulted to false for the time being, as the bandwidth usage can be
high. This allows users to avoid the need to bootstrap the remote first
by enabling flakes on the remote Nix binary.
This initializes ./test/default.nix which is referred to by the
flake.nix under the `checks` attribute. This default.nix should point to
all future tests, where they can be looked up and ran like:
nix build .#checks.x86_64-linux.vmTest
The test included is a simple NixOS VM Test. It uses Nixinate to deploy
a machine with `services.nginx.enable = true` set, and tests whether
nginx.service is started and reachable after deployment.
