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.
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.
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