it seems that the `cache-from` feature of the pulu...
# general
c
it seems that the
cache-from
feature of the pulumi docker go implementation is broken: https://github.com/pulumi/pulumi-docker/issues/238 I can hack around this by: 1. pulling the image I want to use as a cache 2. manually running
docker build --cache-from my-image
3. executing `pulumi preview`/`pulumi up` My intuition tells me that the manual
docker build
step should populate the layer cache and therefore speed up the pulumi commands which build the docker image but I’m finding that even with this workflow pulumi recreates the docker image from scratch. Is my intuition incorrect? If so how? Is there another way I can hack around the current bug with cache-from in the go implementation?
b
That code is from several months ago but it worked.
c
oh nice! What language is that example? It doesn’t look like go to me - because of the
List<string>
and go doesn’t have generics
b
C# but the same should apply I think.
c
does this require a minimum docker version? I notice you’re using
DOCKER_BUILDKIT
and it’s inline cache
also, I think the
CacheFrom
for go is broken - is the CacheFrom for your example critical for caching to work?
b
ah, I see, that would be a problem. The CacheFrom in the code I posted is basically a list of strings that are the stages in to cache in the Dockerfile. It looks like 18.09 or higher.
c
ah yup, unfortunately CacheFrom is totally broke in the go implementation 😞
does the buildkit inline cache require the cache-from arg or do they operate independently of each other?
b
I believe the inline cache env var is required for cache from to work for remote caching, but I'd have to check that.
c
got it, yeah I’m wondering if I can just set
DOCKER_BUILDKIT
and use
BUILDKIT_INLINE_CACHE
and skip using
CacheFrom
entirely.
170 Views