#Are there any updates on enabling remote
rigid escarp
I may be wrong, but you probably don't want that config at the engine config level, because it's very payload-specific. ie. if you run pipelines for different apps on the same engine, you'll want a different cache export config. Heck you'll even need a different config per environment eg. different cache export config for main vs. each PR for example
hasty lake
certainly for dev vs CI
rigid escarp
But even within CI. You won't have a single CI config for a given app is my guess
hasty lake
For our CI, I think we'd want a uniform cache policy, since we have a mega-monorepo and our cross-branch builds would benefit
rigid escarp
Of course that would be great. But buildkit cache export won't support it in the way you hope, I think
hasty lake
they already do benefit significantly on a single machine
it's more about cross-worker caching to get more juice out of the machine
rigid escarp
You'll have to give more details about what you're hoping that buildkit config will do. My feeling is that you might be overestimating what that feature does out of the box
hasty lake
yeah, I'm light on details of how BuildKit cache actually works
the tl;dr from our side is that we have workloads that would cache in Dagger if they ran on the same worker, but don't today because each worker has its own instance of the engine running
we also use ephemeral workers, so having the cache outlive the instances would be ideal as well
This is tempting as a simple experiment: https://cloud.google.com/compute/docs/disks/sharing-disks-between-vms
rigid escarp
This is the most common question when taking Dagger to production... how to solve the lack of caching in "vanilla" CI environments (ephemeral runners, no Dagger-specific infrastructure).
The short answer is: there's no silver bullet, but there are options. The best option depends on your constraints. We are working on more options. And eventually, we will produce the silver bullet 🙂
Buildkit cache export is one such option - most definitely not a silver bullet though.
The main limitation of buildkit caching, is that each run exports the cache produced only by that run, and overwrites previous content. So you need to very careful orchestrate the cache key, in a workload-specific way, to get acceptable cache performance.
BK cache export will not allow for a bunch of workers to transparently reuse each other's cache. It's more manual, and more brittle than that.
hasty lake
lol, I'm not surprised by this revelation
I'd imagine something more where the hash-input Dagger uses to know whether to use the local cache would be the key for a remote registry layer
like it already knows to use the local cache across branches/builds, so add a check against a remote registry for when it's not found locally...?
rigid escarp
That's the easy part, the hard part is writing new entries to the cache
hasty lake
would one not write each node of the DAG used in the computation/solver as a layer?