-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
set base image annotations by default according to OCI image spec #2756
Comments
Kindly ping @crazy-max @tonistiigi 🙋🏻♂️ |
I'm willing to do this as well 🤩 |
As described in the other issue I think our new buildinfo features are superior to this annotation that only captures a single specific field for a specific build type. Adding custom user-defined annotation support is fine though as described in #1220 |
I somewhat disagree. Though buildkit's buildinfo references will tell you about more images involved in building the image (esp multistage build stages, and buildkit frontend interpreters), AFAIK there's no way to identify which of those image represents the "base" of the final produced image. The OCI annotations only tell you that, but it does (intend to) make it clear that's what's being communicated. This came up a lot in the discussion about the OCI annotations, and we decided that since "multi-stage builds" aren't a thing in the general OCI landscape, only in buildkit/Dockerfile-originating builds, that it would be more useful to limit the scope of the annotation to only communicate "this image shares base layers" and not "this image was nebulously involved in building your image" |
There is no such thing as "base" for an image. Images can be created in a lot of ways, not only via Dockerfile and not only via Dockerfile that uses If you want to see if one of the build sources shares the same layers as the top layers of the image only thing you need to do is pull a manifest or config for both of them and see if the layers property is a subset of the other. |
I agree! (And even made many of the same points in the many discussions about the OCI annotations 😆) But, when there is an easily-defined base -- that is,
That is certainly another approach. However, given an image of unknown provenance, there's no effective way to identify its base aside from comparing it to a list of possible base images, and all old versions of those images, including images where the tag may have changed and is no longer present in the registry due to GC. Having a build tool insert this information -- a subset of the same information present in buildinfo today -- narrows the field considerably. Tooling should still inspect and verify the value is correct (the base image's layers equal the built image's layers[0:N]), but at least they don't have to scan a universe of possible base images to find it. |
According to the discussion on Slack: docker/roadmap#243 (comment)
I know BuildKit provides an additional image config for reproducibility, but as @imjasonh asked, would it make sense also to have BuildKit put that information into annotations (when/if it produced OCI images that support image annotations)?
Here is the spec: https://github.com/opencontainers/image-spec/blob/main/annotations.md#pre-defined-annotation-keys
The text was updated successfully, but these errors were encountered: