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.
Motivation
I manage all of my systems with Nix, so this grew out of me doing various work around Zebra the past few months. I currently merge this branch into whatever I’m working on (which is easy, because this basically only adds new files1, so no conflicts).
I also saw @teor2345 had previously put up a Nix derivation in #1479, which roughly corresponds to nix/packages/zebra in this PR.
Solution
Here is a summary of what’s added.
${system}
can be replaced with any ofaarch64-darwin
,aarch64-linux
,x86_64-darwin
,x86_64-linux
.packages
are builds of the main content of this repochecks
are various tests (other thancargo test
, which is covered bypackages
)*Modules
allow you to configure zebrad like this*Configurations
are examples of those configurations that are built as tests of much of the flakedevShells
provide a sandboxed development environment withrustc
,cargo
, etc.Tests
Everything is built on aarch64-darwin, aarch64-linux, and x86_64-linux at garnix, which also runs the various checks (clippy, fmt, etc.), and it builds the example configurations which implicitly tests the overlays, modules, etc.
For these CI builds to run on not-my-fork, the ZcashFoundation org would need to get a garnix account, or would need to add some Nix-based GitHub workflow (ideally with some caching solution, which garnix handles automatically).
Follow-up Work
The current solution has everything in there, but I think the Nix/Rust tooling could be improved wrt cache-friendliness. It currently uses crane, which condenses everything into only two packages (“zebra”, containing all the crates in this repo, and “zebra-deps”, containing all the dependency crates not in this repo), so if any part of Zebra changes, all of Zebra gets rebuilt, and if a dependency changes, all of Zebra and all deps get rebuilt. Having a separate package for each crate would minimize rebuilds, so a solution like cargo2nix or crate2nix is probably the way to go longer-term2.
The derivation is built with
ZEBRA_SKIP_NETWORK_TESTS
, because of Nix sandboxing3. But even so, there are a number of failing tests that I’ve explicitly skipped. That file conditionalizes them so you can see in which contexts they fail. One thing I didn’t conditionally enable is tests that pass outside of a sandbox, because I think that makes the dev / CI divide confusing. E.g., a number of disabled tests can pass if__darwinAllowLocalNetworking
is enabled, but that can only be done outside of a sandbox. Also interesting is that there are a number of tests that only fail when theelasticsearch
feature is enabled (and only on MacOS).This PR doesn’t provide a default.nix or shell.nix (#1479 did, just under a different name), because I do everything with flakes, but it’s easy enough to expose them with flake-compat if that’s desired.
PR Author's Checklist
PR Reviewer's Checklist
Footnotes
There are three minor changes to existing files:
Alias
from systemd/zebrad.service.They’re not being used yet because of a bug in Nix ([OS X] Derivation fails with sandbox NixOS/nix#4119) that prevents packages with a lot of dependencies from building in a sandbox on MacOS (which would cause failures on garnix CI, as it requires everything to be sandboxed). ↩
There are ways to enable network access in a sandbox, so that might allow all (or at least more) tests to be enabled. ↩