Actual behavior
When using --no-push with --cache=true (and --cache-repo=my-reg) Kaniko will not push any cached layers to the registry.
INFO[0007] Pushing layer my-reg/cache/52445215:35656a0e1... to cache now
INFO[0007] Skipping push to container registry due to --no-push flag
This is undocumented and a bit unexpected given the presence of the --no-push-cache flag.
Expected behavior
Be able to not push the final image with --no-push but still benefit from cache being pushed.
Additional Information
Our use-case and workflow is that we do not push images immediately after Kaniko builds them, but instead save them as tars (--tar-path) and then scan them with a container vulnerability scanner in the CI pipeline. Once that's passed the tar image is pushed to the registry.
The changes that #2752 brought were completely unexpected. I bet a lot of people were using the pushed layers in their pipelines.
I think this issue is the right way to do it.
Actual behavior When using
--no-push
with--cache=true
(and--cache-repo=my-reg
) Kaniko will not push any cached layers to the registry.This is undocumented and a bit unexpected given the presence of the
--no-push-cache
flag.Expected behavior Be able to not push the final image with
--no-push
but still benefit from cache being pushed.Additional Information Our use-case and workflow is that we do not push images immediately after Kaniko builds them, but instead save them as
tar
s (--tar-path
) and then scan them with a container vulnerability scanner in the CI pipeline. Once that's passed thetar
image is pushed to the registry.It seems like this used to work before https://github.com/GoogleContainerTools/kaniko/pull/3132/files was merged. It seems to fix an issue (#2752) that probably should have used the
--no-push-cache
option instead of the--no-push
option.Ideally the cache should be pushed as long as the
--no-push-cache
flag is not provided, regardless of the--no-push
being present or not.Triage Notes for the Maintainers
--cache
flag