The cache key generation does environment subsitution in places that running
the commands doesn't. This causes issues if a command uses complex shell
substitutions. The cache key is generated even if caching isn't enabled.
This disables the cache key generation if caching is not enabled. This doesn't
fix the underlying issue, but limits it to when the cache is being used.
Kaniko by default used to configure the GCR credential helper however
this caused Kaniko to fail when trying to use a base image from a public
GCR image. This patch makes it possible to use public GCR images as base
image when using docker even when you're not authenticated to GCR.
Co-authored-by: Nate Williams <nate.williams@files.com>
Add unit tests that check the behaviour of CompositeCache
on adding filesytem resources. It checks that
* 2 identical directory trees produces the same hash
* an extra file produces a different hash
* an extra directry produces a different hash
* an extra file that is excluded does not alter the hash
* an extra directory that is excluded does not alter the hash
Previously kaniko would compute the cache key for any copy command by computing
the combined hash of all files in a directory, even if they were listed
as ignored.
With this change, the cache key creation was updated to be aware of ignored
files.
Related issues:
* https://github.com/GoogleContainerTools/kaniko/issues/594
* Update cached copy command to return the same result for
files used from context so that cached and uncached copy
commands produce the same cache key
* Update tests for fix
* Add test for cached run command key consistency
* use the cachekey of the src stage rather than the digest
for COPY --from commands as they are reproducible unlike digests
* track digest to cache keys and stage indexes to digest
* add extra debug logging for troubleshooting cachekey building issues
* convert Sha256 hashes to hex encoded strings rather than plain strings
for easier human reading
Store the last cachekey generated for each stage
If the base image for a stage is present in the map of digest
and cachekeys use the retrieved cachekey instead of the base image
digest in the compositecache
Fixed#296.
The output manifests may have `application/vnd.docker.distribution.manifest.v2+json`
as their media types instead of `application/vnd.oci.image.manifest.v1+json`.
Resolves#607
* Deleted a duplicate Gopkg.lock block for github.com/otiai10/copy to
prevent `dep ensure` from deleting it from vendor/
* Searched for breaking changes. Only found ones for
remote.Delete/List/Write/WriteIndex. Searched for those and fixed
* Noticed that NewInsecureRegistry was deprecated and replaced it
* Revert "Change cache key calculation to be more reproducible. (#525)"
This reverts commit 1ffae47fdd.
* Add logging of composition key back
* Do not include build args in cache key
This should be save, given that the commands will have the args included
when the cache key gets built.
This flag, when set, takes a file in the container and writes the image digest to it. This can be used to extract the exact digest of the built image by surrounding tooling without having to parse the logs from Kaniko, for example by pointing the file to a mounted volume or to a file used durint exit status, such as with Kubernetes' [Termination message policy](https://kubernetes.io/docs/tasks/debug-application-cluster/determine-reason-pod-failure/)]
When the flag is not set, the digest is not written to file and the executor behaves as before. The digest is also written to file in case of a tarball or a `--no-push`.
Closes#654
Tom Prince
Dani Raznikov
Tejal Desai
Sam Stoelinga
Vincent Latombe
Ben Einaudi
Yoan Blanc
Cole Wippern
Moritz Wanzenböck
Cole Wippern
Moritz Wanzenböck
Nao YONASHIRO
Will Ripley
Victor Noel
Don McCasland
alexa
Prashant
chhsia0
Deniz Zoeteman
Andreas Bergmeier
Taylor Barrella
Andreas Bergmeier
priyawadhwa
Gijs
Johannes 'fish' Ziemke
dlorenc