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 cache.nixos.org 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
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): https://github.com/drupol/milewski-ctfp-pdf/pull/7
I don’t know yet how to tackle this.
I opened this issue: https://github.com/actions/cache/issues/749 since I’m unable to restore
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.
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.