Closed bjeanes closed 6 months ago
Hi @bjeanes, interesting idea. Actually, the plugin does not use neither the cache-to
nor the cache-from
options from docker's buildx
as it was created before BuildKit even existed. Instead, the cache-from
option (the only one implemented) parses the configuration options in a very specific form and runs the corresponding docker pull
commands on the images to populate the docker layers that may be re-used during the build process (AKA, the inline cache).
The end result is the same and it is even compatible with older docker versions (that do not have buildkit enabled). Though it may be a good idea to replace this feature with the corresponding newer features when we do some incompatible changes, like defaulting to version 2 of the plugin (see #390)
@toote
So if cache-from is enabled do we still need to set BUILDKIT_INLINE_CACHE=1
meaning are both mutually exclusive.
@farhansaed sorry for the delay, we've been busy working and testing some breaking changes that affect the way cache-from
options work (see #419).
So if cache-from is enabled do we still need to set BUILDKIT_INLINE_CACHE=1 meaning are both mutually exclusive
If you are using the plugin's option cache-from
at this time (version 4.16.0), BUILDKIT_INLINE_CACHE
is not necessary at build time because the plugin will try to pull images in its cache-from
configuration (according to some very specific logic) to be able to re-use the corresponding layers.
If you are referring to docker's cache-from
option, its documentation is very clear:
To use an image as a cache source, cache metadata needs to be written into the image on creation. You can do this by setting --build-arg BUILDKIT_INLINE_CACHE=1 when building the image. After that, you can use the built image as a cache source for subsequent builds.
So the answer, as with most things, is depends on whether you are referring to this plugin's cache-from
option, or docker's cache-from
option. But they are definitely not mutually exclusive, just maybe not necessary. This difference should no longer be a factor in the future when #419 is merged and release as the plugin's cache-from
option will be directly mapped to docker's option (with all its advantages, like any caching backend supported by docker, and its disadvantages, like the requirements for the inline cache to be baked into images.
I had a squiz through the build.sh code and the docs and it seems that this plugin only uses the
inline
cache (assuming you set build argBUILDKIT_INLINE_CACHE=1
). We are moving towards multi-stage builds for a number of reasons and the Docker docs recommend using theregistry
cache in that case. I think the implication is thatinline
cache will only cache the final/target stage.Presently, this plugin doesn't have a way to set
cache-to
, relying exclusively on theBUILDKIT_INLINE_CACHE=1
methodology for activating theinline
plugin, which appears to have no equivalent forregistry
caching.Further, I'm not sure whether
build.sh
would tolerate the syntax of--cache-from type=registry,ref=<registry>/<cache-image>
vs--cache-from=<registry>/<cache-image>
, but this is just based on reading the code.Has this direction been explored yet?