Caching /nix/store in GitHub actions

hey! I’m exploring GitHub actions on a Haskell project and pulling down packages takes a while, roughly 3m30s of the build. This isn’t an awful time but I feel bad pulling all my packages from every build.

GitHub does offer a cache action which I can use to store /nix/store in a big ol’ bundle somewhere that’s quite fast for GitHub Actions to load. When I try to use it, it’s able to pack /nix/store, and download the artifact on the next build, but then it has a lot of permissions errors when trying to unpack to /nix/store!

I’m sure someone has got this working out there, and while I could continue to beat my head against it (maybe by making /nix/store first and assigning the correct permissions?) I figured I’d just ask! Does anyone have this working? How did you do it?


I haven’t tried caching /nix myself, but especially for anything involving GH actions I’d recommend a GH code search.

I’m not certain it solves your issue (and I’m not aware of having seen the author around on discourse), but I did find GitHub - rikhuijzer/test-caching: Cache Nix packages (along with a few other repos by the same user that seem to use this approach) via a GH search for language:yaml, “actions/cache”, and “cachix/install-nix-action”.

oh, cool. This does make sense. I’ll try it; thanks!

I’m trying to cache /nix directory using the official Github Actions Cache, but I’m having troubles when trying to restore it (a lot of permissions denied):

I don’t know yet how to tackle this.

I opened this issue: since I’m unable to restore /nix/store.

1 Like

I would definitely consider giving cachix a shot! You can see how to use it eg here.

Cachix will still require a download from a remote, right? I don’t quite see how it speeds up actions in this case; the point is downloading dependencies already cached by upstream, just closer to the runner.

1 Like

I’d guess you generally can’t recover pathes that are not owned by the build user, this is unrelated to nix and just how Linux permissions work.

I understand the wish to get a single huge tarball over many small ones. Especially if there is a semi-guarantee that the huge tarball comes from within the same region or data center even…

Exactly, AFAIK, cachix is good for caching the result of a build, not for something else.

That’s exactly the point. The idea is to download once the dependencies and to use them in different jobs, without downloading anything else.

I don’t know, I opened an issue , I hope to get some answers soon.

1 Like