Open ziptie opened 3 years ago
When the cache is enabled, Kaniko wants to store built layers in a repository. When --cache-repo
is not specified, that cache repo is inferred from the --destination
flag. But when you disable pushing the final image, you need to tell Kaniko where it should store the cached layers, hence the requirement to specify --cache-repo
.
I don't think you can opt into base-image caching without opting into layer caching as well.
I think this is a side-effect of the unfortunate choice to use the same --cache flag for both caching input dependencies, and caching intermediate build steps. Maybe explicitly separating the two (very different) concepts would make sense? I am sure that my use case is not unique, ie wanting to build images without interacting with remote repositories. Being able to provide the build dependencies produced with warmer and dumping the result as a local tarfile is ideal. Having --cache also force intermediate layer pushes to some remote is not.
--cache-dir
totally makes sense to use with with --no-push
when we don't want to push the image yet, but want to store the cache somewhere in a local file system to avoid delays checking the remote repository.
This should be on the roadmap, since local cache is significantly faster than the remote one
For context, I am trying to use kaniko to build docker images in a gitlab-ci stage, to be stored only as tarfiles and with no network interaction at all. I have run warmer and saved the cached base image to /cache. I have specified --no-push, --cache=true, and --cache-dir /cache, but am getting the following error:
Error: cache flags invalid: if using cache with --no-push, specify cache repo with --cache-repo
This is the line that performs the check, https://github.com/GoogleContainerTools/kaniko/blob/a0c96b4edcaeee437243484f5880833518d06551/cmd/executor/cmd/root.go#L216 Hopefully this is just an untested use case, and the fix is trivial . Thanks for a really useful tool!