[flurie]

Have you considered bundling that env into your CI image? I have a CI/CD process that will build and update an image with the environment pre-loaded. It doesn't save you the data transfer, but it likely provides a better warm cache.

[mtlynch]

I've thought about it, but I'm not sure how that would work. Because for me, the value proposition of having a Nix flake for my project is that I can bind the exact dependencies to the state of the code in my repo. So if I want to update from Go 1.19 to Go 1.20, I just update a line or two in my flake.nix. If I have to go update a separate repo, build a Docker image from that repo, then update the tag in my real repo, it kills the convenience.

Is there an easier way to do it?

Also, wouldn't it be pretty similar performance-wise to caching the /nix path on a generic Nix image? I've tried that, but it has problems because the Nix path ends up being a few GB, so that ends up adding a long time to the build as well.

[flurie]

It might help to describe how I employ this. I own the build and infra for a fairly large monorepo, and I moved all of the deps to Nix. I have a few ways to source/build things:

- A bare image with just Nix can pull the deps from a cache.

- A pre-built image contains the deps from the latest push to default branch and nothing else.

I do not maintain a separate repo for this. Part of my CI is building and caching the paths. And then CD is building and pushing the image, which the CI has verified as working. This requires using a mutable tag, but you could also have the CD process auto-update the tag if this is not an option.

You're correct that this doesn't save you from having to get the same amount of data to the same place, but the image repo can usually be cached more advantageously for whatever is pulling images, so it should be considerably faster overall.