awkawbandClaude Sonnet 5
c8a67b1208
Adds an invoiceninja-nixos flake input and two things built from it: - nixosConfigurations.invoiceninja-test-nginx/-caddy: manual test VMs, re-exported as-is from that repo rather than redefined here — same principle as this crate being a client of the SDK, not a second implementation of it. - checks.invoiceninja-cli: an automated nixosTest (tests/, adapted from invoiceninja-nixos's own test scaffolding) that boots a real Invoice Ninja instance and runs the actual invoiceninja-cli binary against it - create/list/get/update/invoice/payment/delete across clients, invoices, and payments - rather than raw curl. tests/common.nix's module import had to change from a relative ../nixos-module/invoiceninja.nix (which doesn't exist here) to a parameter threaded from the flake input's nixosModules.invoiceninja. Building the VM pulls from the invoiceninja-nixos cachix cache via a nixConfig block, mirroring that repo's own. Also fixes a wrong assumption the first version of this test's final assertion made, caught by actually running it against a real server: `clients list` with no `--status` does not exclude soft-deleted records - confirmed empirically (Invoice Ninja returns everything regardless of is_deleted unless status=active is passed explicitly). Corrected the test to check is_deleted via `clients get` instead, and fixed the misleadingly-incomplete --status doc comment in cli.rs that had the same wrong assumption baked in. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
53 lines
2.8 KiB
Nix
53 lines
2.8 KiB
Nix
{ proxyServer ? "nginx", invoiceninjaModule }:
|
|
{ pkgs, modulesPath, ... }:
|
|
|
|
{
|
|
imports = [
|
|
(modulesPath + "/profiles/qemu-guest.nix")
|
|
# Not imported by default for a plain nixosSystem in this nixpkgs (only nixosTest nodes get it
|
|
# automatically) - needed explicitly so virtualisation.cores/memorySize below are real options.
|
|
(modulesPath + "/virtualisation/qemu-vm.nix")
|
|
(import ./common.nix { inherit proxyServer invoiceninjaModule; })
|
|
];
|
|
|
|
# `nix flake check` evaluates config.system.build.toplevel directly, which asserts a real root
|
|
# filesystem and bootloader are configured. `just build-vm` builds config.system.build.vm
|
|
# instead, where the qemu-vm module overrides both of these with a tmpfs root and direct
|
|
# kernel boot (virtualisation.useBootLoader defaults to false) - so these values just need to
|
|
# satisfy the assertions and are otherwise unused.
|
|
fileSystems."/" = {
|
|
device = "/dev/disk/by-label/nixos";
|
|
fsType = "ext4";
|
|
};
|
|
boot.loader.grub.enable = false;
|
|
|
|
users.users.root = {
|
|
initialPassword = "toor";
|
|
};
|
|
|
|
services.resolved.enable = true;
|
|
|
|
# `just boot-vm` forwards the guest's port 80 to host port 8080 (QEMU_NET_OPTS in the justfile),
|
|
# but the backend builds absolute URLs (e.g. the stored company logo path) from APP_URL, which
|
|
# defaults to plain "http://localhost" with no port. The SPA's own relative URLs are fine (they
|
|
# inherit whatever port the browser is already on), but any backend-generated absolute URL then
|
|
# points at host port 80 - where nothing is listening - instead of the forwarded 8080, giving a
|
|
# silent net::ERR_CONNECTION_REFUSED for things like the logo image. Override to match the actual
|
|
# forwarded port.
|
|
services.invoiceninja.settings.APP_URL = "http://localhost:8080";
|
|
|
|
# The qemu-vm module's defaults (1 core, 1024MB) are too tight for real interactive use: MySQL +
|
|
# Redis + PHP-FPM + chromium (PDF generation, spawned per request - each is a full multi-process
|
|
# browser, not a lightweight renderer) running concurrently can exhaust 1GB fast, and this VM
|
|
# boots with panic_on_oom - so it's not a graceful slowdown, the whole VM goes down. Confirmed by
|
|
# reproducing a "logo upload hangs" report this way: at the 1024MB default, even a couple of
|
|
# concurrent PDF-generation requests triggered `redis-server invoked oom-killer` and a kernel
|
|
# panic. 2 cores / 2560MB comfortably handles 2 concurrent PDF generations alongside normal
|
|
# traffic (verified: ~1.4GB still free afterward); a deliberate flood of many concurrent PDF
|
|
# requests can still exhaust even this, since each is a full chromium instance - if that's a
|
|
# concern for your deployment, consider capping `phpfpm.settings."pm.max_children"` below its
|
|
# default of 8, or provisioning more RAM.
|
|
virtualisation.cores = 2;
|
|
virtualisation.memorySize = 2560;
|
|
}
|