closes#93.
note that this includes classes:
- `nixos`
- `nixosTest`
- `nixops4Resource`
- `nixops4Deployment`
.. and my (made-up, as per the [docs](https://ryantm.github.io/nixpkgs/module-system/module-system/#module-system-lib-evalModules-param-class)):
- `nix-unit`
- `package`
.. while i did not manage to cover:
- service tests, given `pkgs.nixosTest` seemed to not actually like `_class = "nixosTest"` (?!)
... nor #93's mentioned destructured arguments for that matter, as per Fediversity/Fediversity#93 (comment) - let me know if that is still desired as well.
Reviewed-on: Fediversity/Fediversity#398
Reviewed-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Kiara Grouwstra <kiara@procolix.eu>
Co-committed-by: Kiara Grouwstra <kiara@procolix.eu>
later we may want to distinguish dev vs host as well, tho eventually we expect not to have hard-coded machines anyway.
split off from #319.
Reviewed-on: Fediversity/Fediversity#367
Co-authored-by: Kiara Grouwstra <kiara@procolix.eu>
Co-committed-by: Kiara Grouwstra <kiara@procolix.eu>
Closes Fediversity/Fediversity#276
This PR adds a CLI deployment test. It builds on top of Fediversity/Fediversity#323. This test features a deployer node and four target nodes. The deployer node runs `nixops4 apply` on a deployment built with our actual code in `deployment/default.nix`, which pushes onto the four target machines combinations of Garage/Mastodon/Peertube/Pixelfed depending on a JSON payload. We check that the expected services are indeed deployed on the machines. Getting there involved reworking the existing basic test to extract common patterns, and adding support for ACME certificates negotiation inside the NixOS test.
What works:
- deployer successfully runs `nixops4 apply` with various payloads
- target machines indeed get the right services pushed onto them and removed
- services on target machines successfully negotiate ACME certificates
What does not work: the services themselves depend a lot on DNS and that is not taken care of at all, so they are probably very broken. Still, this is a good milestone.
Test it yourself by running `nix build .#checks.x86_64-linux.deployment-basic -vL` and `nix build .#checks.x86_64-linux.deployment-cli -vL`. On the very beefy machine that I am using, the basic test runs in ~4 minutes and the CLI test in ~17 minutes. We know from Fediversity/Fediversity#323 that the basic test runs in ~12 minutes on the CI runner, so maybe about an hour for the CLI test?
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Reviewed-on: Fediversity/Fediversity#329
Reviewed-by: kiara Grouwstra <kiara@procolix.eu>
Reviewed-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@moduscreate.com>
Co-committed-by: Nicolas “Niols” Jeannerod <nicolas.jeannerod@moduscreate.com>
adds a deploy button to the panel form - covers the local part of #76.
As a workaround to pass info (from our user form) into nixops4 uses
environment variable `DEPLOYMENT` thru nix's
`--extra-experimental-features configurable-impure-env`.
- simplify the configuration module
the `package` attribute makes little sense to be user-configurable,
since it will always need to be the derivation defined in this very
repository. for debugging one may as well change the original code itself.
- unbreak deployment
setting `CREDENTIALS_DIRECTORY` disabled the systemd mechanism set up
in the configuration module.
- remove unneeded configuration for deployment
- unbreak integration tests
before that missed waiting for the service to create some
state before running the application-level tests.
