Skip to content

Conversation

@rumpl
Copy link
Owner

@rumpl rumpl commented Nov 25, 2022

Including buildkit's custom properties

@rumpl rumpl requested a review from vvoland November 25, 2022 15:17
"github.com/docker/docker/image"
"github.com/docker/docker/layer"
"github.com/docker/go-connections/nat"
buildkitimage "github.com/moby/buildkit/frontend/dockerfile/dockerfile2llb"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
buildkitimage "github.com/moby/buildkit/frontend/dockerfile/dockerfile2llb"
"github.com/moby/buildkit/frontend/dockerfile/dockerfile2llb"

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough, fixed, thanks

Including buildkit's custom properties

Signed-off-by: Djordje Lukic <djordje.lukic@docker.com>
@rumpl rumpl merged commit c6f62ba into c8d Nov 30, 2022
@rumpl rumpl deleted the fix-image-props branch November 30, 2022 00:46
}

var ociimage ocispec.Image
var ociimage dockerfile2llb.Image
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused here; so this is using;
https://github.com/moby/buildkit/blob/v0.10/frontend/dockerfile/dockerfile2llb/image.go

That type is effectively deprecated in v0.11 of BuildKit (but not aliased but defined as a duplicate of the type);
https://github.com/moby/buildkit/blob/v0.11.0-rc1/frontend/dockerfile/dockerfile2llb/image.go#L11

The new type is here:
https://github.com/moby/buildkit/blob/v0.11.0-rc1/exporter/containerimage/image/docker_image.go

And, IIUC, it's effectively a fork of the type that is defined in Docker.

So, docker now depends on a fork of itself to define the type?
https://github.com/moby/moby/blob/v23.0.0-beta.1/api/types/container/config.go#L35-L54

Can we fix this, because this looks really weird

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The last type you linked is an api type, we shouldn't use it for reading things, only for writing to it and sending to the caller.

That being said then moby doesn't have any type that defines a HealthConfig.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But how is the dockerfile2llb type different? That's also an API type; it's the type to export to JSON

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The dockerfile2llb type is used to store the image, that's why it's later moved over to the exporter. We should use the same type that is used to save the image when we load it. Then we can convert it to our own types.

This type is the type that we use for the engine API. It should be independent of anything else.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Put in another way: the dockerfile2llb type is different in a sense that it's a buildkit's type. We have our own for the engine API. They both look the same, but they are not the same

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

5 participants