We at Determinate Systems are excited to announce the Magic Nix Cache, a GitHub Action that can dramatically speed up your Nix workflows. It uses the GitHub Actions Cache API as a repo-level Nix binary cache, it automatically pushes any newly created Nix store paths during workflow runs, and it gracefully handles any rate limiting by the Actions Cache API. We’re confident that this will provide immediate zero-cost benefits to Nix projects of all kinds.
I tried adding the one line of yaml to my workflow, but everything is still downloaded from cache.nixos.org. How is nix supposed to know about the local binary cache daemon? Do we need to configure this explicitly when not using the DS action to install nix?
It uses cache.nixos.org as its upstream cache by default (though you can select a different one). See the available options. The Magic Nix Cache explicitly avoids caching anything that it fetches from the configured upstream cache.
You don’t need to explicitly configure Nix because the Action updates your Nix configuration to use the running daemon as a substituter (see this line), and it does so regardless of how you install Nix in the environment.
Hmm, why can’t we cache also the store paths that were fetched from the cache? It would at least reduce traffic to cache.nixos.org and instead fetch from an internal github resource.
While GitHub is pretty generous with cache space (see here), it’s not unlimited. The Magic Nix Cache Action strives to be parsimonious about what it caches, and when it “knows” that it will be able to fetch rather than build something in the future, it opts not to cache.
Currently, I am snapshotting /nix/store instead of saving individual derivations. I was going to build this exact project to improve caching I guess less work for me
It’s quite likely that I’ll keep snapshotting as an optional feature, I assume it is more performant for larger builds
Nice! I was about to switch one of my projects to it, but then reminded myself that I already have cachix intergration in that project (which I want anyways). There is probably little point adding the magic-nix-cahe-action in that case, is there?
You may well see some benefit. The Magic Nix Cache uses GitHub cache infrastructure which means artifacts from prior builds are cached and available from infrastructure directly adjacent to the GitHub builders.
I’d certainly be interested to see what benefits you see after several build cycles with the Magic Nix Cache enabled
I guess less work for me 
