Check --cache-repo is provided with --cache and --no-push #374
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As described in GoogleContainerTools#373, kaniko panics when provided with --cache and --no-push since it tries to infer a cache repo from the destination, which doesn't exist. To fix this, I added a check to make sure --cache-repo is passed in when both these flags are provided.
dlorenc
approved these changes
Sep 28, 2018
|
Does Kaniko do any local caching without a remote repo? It would be nice to be able to cache base layers locally without having to push those layers to a repo. |
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this pull request
Jun 13, 2024
Adjust kaniko arguments passed in by build-image: - pass --cache=true to kaniko, otherwise it seems to look for an image named "parent" on docker hub instead of looking at the tar we put in the cache dir - pass a cache-repo to kaniko, otherwise it refuses to enable caching (GoogleContainerTools/kaniko#374) Differential Revision: https://phabricator.services.mozilla.com/D213062
i3roly
pushed a commit
to i3roly/firefox-dynasty
that referenced
this pull request
Jun 14, 2024
Adjust kaniko arguments passed in by build-image: - pass --cache=true to kaniko, otherwise it seems to look for an image named "parent" on docker hub instead of looking at the tar we put in the cache dir - pass a cache-repo to kaniko, otherwise it refuses to enable caching (GoogleContainerTools/kaniko#374) Differential Revision: https://phabricator.services.mozilla.com/D213062
gecko-dev-updater
pushed a commit
to marco-c/gecko-dev-wordified-and-comments-removed
that referenced
this pull request
Jun 16, 2024
Adjust kaniko arguments passed in by build-image: - pass --cache=true to kaniko, otherwise it seems to look for an image named "parent" on docker hub instead of looking at the tar we put in the cache dir - pass a cache-repo to kaniko, otherwise it refuses to enable caching (GoogleContainerTools/kaniko#374) Differential Revision: https://phabricator.services.mozilla.com/D213062 UltraBlame original commit: 55df8fca8ebb22f4cda5fa8a8393c0f88626f65f
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As described in #373, kaniko panics when provided with --cache and --no-push since it tries to infer a cache repo from the destination, which doesn't exist.
To fix this, I added a check to make sure --cache-repo is passed in when both these flags are provided.
Should fix #373