I prefer to keep my ssh configurations centralized, and refer to destinations by 'short names' every where else. This patch enables that. It might be a niche usecase so feel free to reject, but figured I'd make it public for anyone else that wants to use it.
Co-authored-by: Jimmy Reichley <jimmyqpublik@gmail.com>
Reviewed-on: #49
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.
Ironically, I did not properly test that I had made the local and remote
tests distinct. So the exampleFlake was hardcoded to 'local' only. This
meant that building local and remote tests would return the same
results. This commit fixes that. Additionally, I've made
tests/vmTests/common.nix to deduplicate some of the code between nodes.
This creates and uses a function named mkNixinateTest which takes a
buildOn argument. This expects to be either "local" or "remote". This
means we can make a test for both use cases of Nixinate. One where we
build on the remote machine, and one where we build locally and push to
the remote machine. These tests are then added to the top level of the
tests folder and are imported by the flake.nix
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.
