Hacker News Reader

I don’t know about CircleCI but if you can persist the /nix/store then that will give you the performance improvements you’re looking for.

I use Gitlab CI and with self hosted runners I can make sure the /nix/store is persistent across CI jobs and then my builds take ~5 seconds if no code has changed, 5 seconds of which is just nix build evaluating all my nix files and realising no work needs to be done.

View on HN

The problem people often run in to when persisting the nix store is that it can be very large, and updates often. This adds a significant tax on setup/teardown time and sometimes storage costs. The completely free and unsubsidized Magic Nix Cache's design alleviates that on GitHub Actions by persisting each path individually in the actions cache. FlakeHub Cache brings a for-cost component to that, which exposes the cache to your workstation and production infrastructure.

To clarify I meant having /nix/store on some kind of persistent volume rather than copying it at the start and end of every job, that indeed would be painfully slow and extremely inefficient. I don't know if this is possible with CircleCI.

Yes, this is exactly the problem I hit when I try to cache the Nix store on CircleCI.

Reply on news.ycombinator.com