Add NixOS module, container integration test, and restructure flake#1508
Open
Ericson2314 wants to merge 1 commit into
Open
Add NixOS module, container integration test, and restructure flake#1508Ericson2314 wants to merge 1 commit into
Ericson2314 wants to merge 1 commit into
Conversation
Author
|
Ah this didn't build because wherever Linux runner this is using does not support KVM for the VM test. I'll should look into using the new "container tests" instead. |
If we are to refactor Hackage, we want to have more tests to be more confident that we are not making mistakes. This commit reworks the Nix and makes a new end-to-end NixOS container test. Even if we aren't refactoring hackage, more tests don't hurt. (NixOS Container tests are an (exciting!) new variant of the older NixOS VM test concept, and share most of the same infrastructure. I had to use them here because the current GitHub Actions runner doesn't support KVM, but they are nicer in general (quicker, lighter logs, etc.).) The NixOS module (`nix/nixos-module.nix`) provides `services.hackage-server` with Claude's guess at usual options (`baseUri`, `userContentUri`, `port`, `stateDir`, etc.), automatic `init` on first start, and a systemd service matching production deployment conventions. It seems good to me — certainly good enough for testing purposes. The container test (`nix/test.nix`) spins up a NixOS container with the module enabled and does a curl smoke test. This is the first time we have an automated test of the full deployment stack (systemd → init → server → HTTP), not just the Haskell code in isolation. The flake is restructured so that `flake.nix` is a thin wrapper and all the actual configuration lives in `nix/flake-module.nix`. This also introduces `lib.fileset` to whitelist only Haskell-relevant source files, so that editing nix files, documentation, etc. does not trigger a full Haskell rebuild. That was very useful when editing the container test and other nix code — don't want to blow up my debug cycle by waiting for Hackage to rebuild each time! No Haskell source code is modified. The running server, when deployed as it is today, should be entirely the same.
Ericson2314
changed the title
Author
|
OK I reworked this to instead us the brand-new NixOS container tests. If someone can approve approve the CI runs, it should work now! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
If we are to refactor Hackage, we want to have more tests to be more confident that we are not making mistakes. This commit reworks the Nix and makes a new end-to-end NixOS container test. Even if we aren't refactoring hackage, more tests don't hurt.
(NixOS Container tests are an (exciting!) new variant of the older NixOS VM test concept, and share most of the same infrastructure. I had to use them here because the current GitHub Actions runner doesn't support KVM, but they are nicer in general (quicker, lighter logs, etc.).)
The NixOS module (
nix/nixos-module.nix) providesservices.hackage-serverwith Claude's guess at usual options (baseUri,userContentUri,port,stateDir, etc.), automaticiniton first start, and a systemd service matching production deployment conventions. It seems good to me — certainly good enough for testing purposes.The container test (
nix/test.nix) spins up a NixOS container with the module enabled and does a curl smoke test. This is the first time we have an automated test of the full deployment stack (systemd → init → server → HTTP), not just the Haskell code in isolation.The flake is restructured so that
flake.nixis a thin wrapper and all the actual configuration lives innix/flake-module.nix. This also introduceslib.filesetto whitelist only Haskell-relevant source files, so that editing nix files, documentation, etc. does not trigger a full Haskell rebuild. That was very useful when editing the container test and other nix code — don't want to blow up my debug cycle by waiting for Hackage to rebuild each time!No Haskell source code is modified. The running server, when deployed as it is today, should be entirely the same.