It this conceptually nix eval cache but uploaded to a website?
I’m curious how far you could get to emulating this by e.g. using actions/cache to cache the evaluation cache sqlite database such that evals between a build and deploy GitHub action job don’t re-evaluate your entire NixOS config again.
This appears to be associating output store paths with flake outputs, allowing you to know what path to realize onto the host. Seems they’re leveraging flakehub as the central service to track this mapping.
Cachix Deploy does something very similar. The difference here appears to be the leveraging of the flake URI for path resolution.
The “improved evaluation times” is really just “not evaluating at all” on the destination hosts. It is unsurprisingly much faster to nix-store --realize <path> and then activate it, then it is to eval/build on the destination host.
Well that is what Nix flake eval cache is today as well. it’s simply a map from resolved flake ref to evaluated value. There is no language-level eval-caching in Nix AFAIK
And you can do centralized evals with Nix today already with just the nix cli. E.g.
nix path-info --eval-store ssh-ng://centralized-evaluator nixpkgshello
This only works for store implementations that speak the daemon protocol I think though.
I wonder if we could extend the BinaryCacheStore implementation to serve cached evals through that. e.g. nix path-info --eval-store https://flakehub.com nixpkgs#hello would work.
You wouldn’t get all that far. That might be fine for doing things inside of Actions but the EC2 example in the blog post wouldn’t work because the instance would need access to the Actions cache.
Surely that wouldn’t be an issue if you were self-hosting the Actions runner? It isn’t that hard to setup.
Also seems avoidable by using a cache system that isn’t tightly integrated with GitHub.
We already have a nix cache system 
If you were self-hosting the Actions runner then you would still need some kind of auth story. So if you were fh applying a NixOS configuration on an EC2 instance, as in the example in the blog post, that instance would somehow need privileged access to the Actions environment. I’m not well versed enough to know if that’s even possible.
I am personally not fond of long-lived self-hosted runners. Especially in public repos they simply don’t provide a strong enough security isolation. nix-daemon isn’t hardened for multi-tenancy. Especially if you deploy pipeline runs on it you’re gonna get pwned very fast. ephemeral runners per GitHub job give a very strong security model – especially paired with device identity for auth (using the runner’s ID token document to auth to AWS, or FlakeHub, for scoped temporary authentication).
I hacked around a local per machine solution for this with a SQLite database which keeps mappings flake repository tree hash -> flake nix store path and flake nix store path#flake output -> nix store path to avoid unnecessary re-evaluation and copy of the flake to the store. This looks like a centralized version, which makes sense!
@lucperkins I’m curious if flakehub supports setting permissions in a way that certain users can only resolve (and retrieve) store paths without giving them access to the flake’s source code. (e.g. for distribution of proprietary software )
i wonder how this compares to GitHub - DanielSidhion/nixless-agent, which seems aimed at a similar use-case
Yes! FlakeHub’s permissions model does not map directly onto GitHub’s, which means that user justme123 could potentially have access to store paths (and the cached contents thereof) but not the flake’s repo itself. In fact, machines can authenticate with FlakeHub via platforms like AWS, and those machines certainly would not have access to the underlying repos.