ci: install Nix with nix-quick-install-action in the docs job - #3
Merged
Conversation
docs.yml's build job spent more time installing Nix than doing its work: 23-26s on DeterminateSystems/nix-installer-action against 8-9s of `nix eval` and ~3s of pip, in a 40-47s job. It builds nothing at all, so the multi-user daemon and 32 nixbld users it stands up are pure overhead. nixbuild/nix-quick-install-action unpacks a single-user Nix in ~1s. check.yml and cachix.yml deliberately keep the Determinate installer, for two different reasons, both now recorded in the workflows. check.yml was swapped too and measured worse, so it is reverted here. nix-installer-action installs *Determinate* Nix, whose parallel evaluator this flake's cross-system forcing exercises directly. Upstream Nix 2.34.7 from the fast installer took `nix flake check` from ~30s to 60s: 7s saved on install, 30s lost on evaluation, 67s against a 42-48s baseline. docs.yml wins the same trade because its evaluation is 8-9s rather than 30s, so doubling it still costs less than the install saves. cachix.yml is the only job that genuinely builds. Single-user Nix cannot set up the build sandbox on ubuntu-24.04, where unprivileged user namespaces are AppArmor-restricted, and Nix's sandbox-fallback defaults to true — it would disable the sandbox and retry rather than fail, silently publishing unsandboxed builds to a public binary cache.
sigma
force-pushed
the
ci/quick-install-nix
branch
from
September 7, 2026 08:54
e125fec to
b90ea10
Compare
sigma
changed the title
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.
docs.yml's build job spent more time installing Nix than doing its work. It builds nothing at all — onenix eval, twopip installs — so the multi-user daemon and 32nixbldusers the Determinate installer stands up are pure overhead.Measured
Baseline, last three runs of each:
docs.yml→ buildnix eval .#manifest8s, 8s, 9scheck.yml→ checknix flake check29s, 31s, 28scheck.yml was swapped too, and measured worse
The first push of this branch moved both eval-only jobs. The
check.ymlresult:nix flake check7s saved on install, 30s lost on evaluation. The cause is that
nix-installer-actioninstalls Determinate Nix (Installing Determinate Nix using the --determinate flag), whose parallel evaluator is roughly twice as fast on this flake — andcheckRegistryforcing every advertised system is exactly that workload.nix-quick-install-actiongives upstream Nix 2.34.7.So
check.ymlis reverted to the Determinate installer, with the measurement recorded in a comment.docs.ymlwins the same trade because its evaluation is 8-9s rather than 30s: even if it doubles, that is +8s against -24s.cachix.yml stays, for a different reason
It is the only job that genuinely builds. Single-user Nix cannot set up the build sandbox on ubuntu-24.04 (unprivileged user namespaces are AppArmor-restricted), and Nix's
sandbox-fallbackdefaults to true — it would disable the sandbox and retry rather than fail, silently publishing unsandboxed builds to a public binary cache. The installer is also only ~14% of a network-bound run there.Note on measurement
This PR run only exercises
check.yml;docs.ymltriggers on push tomain, so its number lands at merge. The projected ~19s saving there is inference from the table above, not an observed CI run.Relates to the open question in tb-e6v: "Fixed per-job overhead (nix-installer + cachix-action setup) and whether runner sizing is worth revisiting."