Clarifications about the cache management

[Arcelone]

Description

I have a GitLab pipeline that runs a build instruction every week and pushes the new image (if there is one) and the associated cache to the repo.

I'm using this setting:

--export-cache type=registry,ref=mysoft:cache
--import-cache type=registry,ref=mysoft:cache

The problem is that the cache changes even when there is no change to the image. This results in caches that are not from the same time as the image. For example, on Sunday 1, there was one new image and one new cache. Then, on Sunday 8, there was no new image because nothing changed, but there was a new cache.

Is this an expected behavior? I read that it's normal because loading the Dockerfile is concidered as an instruction in buildkit, and so is cached.
Should this be a concern? Is there a way to disable cache pushing if no new images are generated?

If anyone has any guidance or recommendations for handling this, I'm open to them.

[tonistiigi]

Yes, this can happen in normal workflows. Cache keys of your new build can change and your new build can result in the same artifact but that artifact now has more cache key options pointing to it.

There are many more complicated cases but here is a simple one:

FROM golang:alpine AS build
WORKDIR /
COPY . .
RUN go build -o /out/myapp .

FROM busybox
COPY --from=build /out/myapp /bin/myapp

If golang:alpine gets updated or there is a change in you build context source code, the cache keys in first stage will have new values. But if go build still returns same binary as it did before then your old cache for last stage is still valid, and your resulting artifact would be the same. In the new build cache you will have metadata cache chains to the same final artifact from both checksums of your source code.