Contract-test our interaction with NixOps4 #90

New issue

Open

opened 2025-01-31 11:04:47 +01:00 by fricklerhandwerk · 1 comment

fricklerhandwerk commented

2025-01-31 11:04:47 +01:00

Owner

NixOps4 is still under heavy development, and we need to make sure that when we're interfacing with it, our code doesn't break when updating NixOps4. Having our own test guards against accidental backwards-incompatible changes on the NixOps4 side that will break our deployments at time of use. Instead we will get notified at time of dependency update by a failing test.

Thinking about it, we probably want to have our entire deployment tested against a simulated environment to exercise all the code paths currently in use...

fricklerhandwerk added the

contributor experience

label 2025-01-31 11:04:47 +01:00

roberth commented

2025-01-31 11:27:26 +01:00

Owner

You can use the nixops4-nixos VM test as a reference. (permalink)

Ideally we also make use of the fact that these tests are modules, so we can factor out common bits if that makes sense.
Probably the deployer node can be factored into a nixops4-nixos.modules.nixosTests.test-infra module or something. Maybe also other things. Options can be added to control testScript and whatnot, as needed.

You can use the [nixops4-nixos VM test](https://github.com/nixops4/nixops4-nixos/blob/main/test/default/nixosTest.nix) as a reference. ([permalink](https://github.com/nixops4/nixops4-nixos/blob/65fe4b132fe299e03ee387d67d3fee1eb4593f4f/test/default/nixosTest.nix)) Ideally we also make use of the fact that these tests are modules, so we can factor out common bits if that makes sense. Probably the `deployer` node can be factored into a `nixops4-nixos.modules.nixosTests.test-infra` module or something. Maybe also other things. Options can be added to control `testScript` and whatnot, as needed.