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.
