[zupo]

What worked great for me for speeding up CI was using Cachix + namespace.so. This works so well I moved all my personal and our company CI to GitHub Actions.

With "it works so well", I mean:

* CI is cheap because namespace.so runners are faster & cheaper than GitHub Actions

* the UX is exactly the same as using vanilla GitHub Actions, namespace.so's runner is a drop-in replacement

* the CI starts up very fast because `/nix/store` is stored on namespace.so's "Cached Volumes" which are like virtual disks attached to the CI runner, so there is nothing to download to prime the cache, Nix can just start running immediately

* https://github.com/cachix/cachix-action uploads whatever Nix builds to Cachix in the background so from this point on if any of our devs pulls the latest code, they don't have to build any derivations locally, and lose time waiting, everything is pulled automatically from Cachix to their machines, they can get right to work. Or if I have to purge the Cache Volume for some reason, nothing needs to be rebuilt, just pulled from Cachix.

It's taken a few years to get this dialed in, but now that it works, it's sooo good!

[biggestlou]

I'd be quite curious to see how using the Magic Nix Cache Action compares to your setup in terms of performance: https://github.com/DeterminateSystems/magic-nix-cache-action

(full disclosure: Determinate Systems employee)

[zupo]

IIUC Magic Nix Cache uses Github Actions Cache, which means there is waiting for the cache contents to be loaded onto the runner instance. This can in no way be as fast as what namespace.so does, which is mounting a disk image with /nix/store.