Add support for hermetic remote builds #20
No reviewers
Labels
No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: tristan/nixinate#20
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "mc/hermetic-remote"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
A hermetic remote rebuild is when Nixinate sends a specific Nix binary to the remote first, then uses it when activating a system closure, rather than using the Nix that is already on the remote. This is defaulted to false for the time being, as the bandwidth usage can be high. This allows users to avoid the need to bootstrap the remote first by enabling flakes on the remote Nix binary.
@ -18,1 +18,4 @@
overlay = final: prev: {
nixinate = {
nix = prev.pkgs.writeShellScriptBin "nix"
''${final.nixVersions.unstable}/bin/nix --experimental-features "nix-command flakes" "$@"'';
You should avoid using Unstable here. Since 2.4 flakes are supported.
@ -18,1 +18,4 @@
overlay = final: prev: {
nixinate = {
nix = prev.pkgs.writeShellScriptBin "nix"
''${final.nixVersions.unstable}/bin/nix --experimental-features "nix-command flakes" "$@"'';
Evaluation time is getting better with Nix releases, so I'd rather use unstable, since 2.4 is pretty slow. Also, there are some determinism issues with lockfile generation that I'd prefer to avoid, by using the latest.