tests: end-to-end install-keepnode install-mechanics check#97
Conversation
Signed-off-by: Kyle 🐆 <kyle@privkey.io>
|
Warning Review limit reached
Next review available in: 46 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. WalkthroughAdds a flake CI check and NixOS VM test that install the keep-node appliance onto a blank disk, verify boot artifacts and the installed system path, and confirm administrator SSH key enrollment and permissions. ChangesKeep-node installation validation
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested labels: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…ift guard) Signed-off-by: Kyle 🐆 <kyle@privkey.io>
What
Add
tests/install-keepnode.nix(checkinstall-keepnode): runinstall-keepnodeend-to-end on a blank disk and assert the install mechanics succeed — partitioning,nixos-installof the real bring-up appliance closure, systemd-boot written to the ESP, and the operator key enrolled into the runtimeauthorizedKeysFile.Why
installer-guards.nixcovers only the abort paths (bad disk, missing key) with a stubbed closure. The successful install path — the thing an operator actually runs on the hardware — was never exercised. This is the scariest untested path for a real bring-up: if partitioning/nixos-install/enrollment is broken, you'd only find out with the hardware in hand.What it proves (deterministically, single VM)
nixospartitions created and labelled.nixos-installinstalled exactly the closureinstall-keepnodewas handed (/mnt/nix/var/nix/profiles/systemresolves to the shipped bring-up closure)./mnt/etc/keepnode/admin_authorized_keys(exact bytes, 0644).Scope / design notes
/mntrather than booting the installed disk. The full second-boot (nixpkgsmakeInstallerTesttwo-nodestate_dir+ OVMF) was prototyped but the actual boot is firmware/TPM-specific and is validated on real hardware (higher fidelity than an OVMF VM); the environment-independent install mechanics are what this proves. Second-boot coverage is a documented follow-up.keepnodeBringupSystemwith one test-only accommodation,canTouchEfiVariables = false, sonixos-install'sbootctl installneeds no efivarfs in the BIOS installer VM (the appliance ships ittruefor the real UEFI box). Nothing else differs.nixos-install-toolson PATH, an existing/mnt), mirroring reality rather than special-casing the installer.installer-iso.Advances keep-node-8r2 (install mechanics; actual-boot coverage tracked as follow-up). Verified locally: passes (345s).
Summary by CodeRabbit