pseudo wadi
Hi, I'm trying to setup docker layer caching of type registry as per this PR(https://github.com/dagger/dagger/pull/4543). Getting this below error while doing same [type=registry;ref=170982004044.dkr.ecr.ap-south-1.amazonaws.com/argonaut/anime-build-gz9je:argo-cache;mode=max] Connected to engine ae7f1373eeca Error: failed to solve: unknown cache exporter: "registry;ref=170982004044.dkr.ecr.ap-south-1.amazonaws.com/argonaut/anime-build-gz9je:argo-cache;mode=max"
Just for the context i'm using dagger to build the existing docker files and using the dagger go sdk (v0.6.1)
silk egret
👋 .
That code changed a bit. Using the latest dagger version, you should be able to set the registry cache export with the same format as you'd set it in buildkit (comma instead of semi-colon)
_EXPERIMENTAL_DAGGER_CACHE_CONFIG="type=registry,ref=127.0.0.1:5000/test-cache" go run main.go
^ that should work
let us know how it goes
pseudo wadi
Hi @silk egret : Thanks for the revert... will try it out and get back
pseudo wadi
Hi @silk egret : Tried it out, it doesn't seems to be working completely. Basically it is able to export to cache repository but doesn't seems to be using existing cached layers for optimising build time... seems like the configuration is only being applied for "--cache-to" but "--cache-from" configuration is missing... is there some additional setting that needs to be configured for dagger in order to enable cache-from for docker buildx during build process for optimisation...
modern coyote
I had the same experience using type=gha
compact igloo
We do set the _EXPERIMENTAL_DAGGER_CACHE_CONFIG value for both exports (https://github.com/dagger/dagger/blob/52d5756ebc97ead1a175c59f812d883a74982a8f/engine/engine.go#L150-L150) and imports (https://github.com/dagger/dagger/blob/52d5756ebc97ead1a175c59f812d883a74982a8f/engine/engine.go#L154-L154 + https://github.com/dagger/dagger/blob/52d5756ebc97ead1a175c59f812d883a74982a8f/core/gateway.go#L51-L51)
And we also have some tests validating remote cache use here: https://github.com/dagger/dagger/blob/52d5756ebc97ead1a175c59f812d883a74982a8f/core/integration/remotecache_test.go#L46-L46
Let us know if there's a specific case showing the cache not being re-used and we can take a closer look.
Also just FYI that we are working on a remote caching solution that integrates with our cloud and doesn't require any configuration at all (just turn it on and it works). It's in a private alpha right now but if you are interested please reach out
modern coyote
@compact igloo I can share dagger logs if it helps
compact igloo
<@949034677610643507> I can share dagger logs if it helps
Wouldn't hurt but the most helpful would be the dagger SDK code you are running and seeing this behavior. The main thing I wanted to double check is whether you aren't running a pipeline where the cache will often be invalidated. One common source of that is loading a localdir and including the .git directory or anything else that frequently changes
modern coyote
Wouldn't hurt but the most helpful would be the dagger SDK code you are running ...
I believe this isn't the case because running the same pipeline locally works with a cache.
@compact igloo Are we sure that Dagger respects "mode=max" attribute? I'm trying to understand how buildkit parses the attributes, and I can't find a reference to mode.
It might explain what I'm experiencing
modern coyote
nvm I think it does respect mode=max
modern coyote
What about withMountedCache(..., d.CacheVolume(...))? Are we exporting and importing cache volumes?