Document image SHAs, avoid build duplication #11
Merged
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
typically causes duplicates, leading to confusion whey you identify images using SHAs (which you should for other people's builds).
solsson
changed the title
helm/charts#144 Beware: This image is 841 MB, compared to 301 for the current :latest. See README.md for upgrade instructions.
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.
Docker's tagging conventions are hard to use. In particular it's difficult to trace a
@sha256:back to the build and thus the source revision. But you do want the checksums because:In addition, with this repo relying on Docker Hub's automated build feature, each tagged build will be a duplicate of the concurrent
:latest(different checksums, identical behavior).You can get reasonable transparency with for example
solsson/kafka:0.11.0.0@sha256:e09d493ae027bbe45d82dc5b9ceaae40adad23efb2936116b233b7dce48136babut the problem is that such image identification isn't explicitly supported by Docker. If the tag is re-built (which is legit, and even implied in case of tags like0.11.0) you'll get "manifest verification failed" at next pull. You could be forgiven for thinking that Docker would continue to use the old pull, but for that you have to omit the tag. Whilesolsson/kafka@sha256:e09d493ae027bbe45d82dc5b9ceaae40adad23efb2936116b233b7dce48136bais stable over time, your colleague has little chance of knowing which Kafka version you intend to run.