Skip to content

Conversation

thaJeztah
Copy link
Member

@thaJeztah thaJeztah commented Apr 4, 2022

ContainerConfig is used in multiple locations (for example, both for
Image.Config and Image.ContainerConfig). Unfortunately, swagger does
not allow documenting individual uses if a type is used; for this type,
the content is optional when used as Image.ContainerConfig (which is
set by the classic builder, which does a "commit" of a container, but
not used when building an image with BuildKit).

This patch attempts to address this confusion by documenting that
"it may be empty (or fields not propagated) if it's used for the
Image.ContainerConfig field".

Perhaps alternatives are possible (aliasing the type?) but we can
look at those in a follow-up.

- A picture of a cute animal (not mandatory but encouraged)

@thaJeztah
Copy link
Member Author

@tonistiigi PTAL

@@ -75,6 +75,10 @@ type ImageInspect struct {

// ContainerConfig is the configuration of the container that was committed
// into the image.
//
// Depending on how the image was created, ContainerConfig, or its fields
Copy link
Member

Choose a reason for hiding this comment

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

For the ContainerConfig field inside image I would say:

ContainerConfig is an optional field containing the configuration of the container that was last committed when creating the image. Previous versions of Docker builder used this field to store build cache and it is not in active use anymore.

ContainerConfig is used in multiple locations (for example, both for
Image.Config and Image.ContainerConfig). Unfortunately, swagger does
not allow documenting individual uses if a type is used; for this type,
the content is _optional_ when used as Image.ContainerConfig (which is
set by the classic builder, which does a "commit" of a container, but
not used when building an image with BuildKit).

This patch attempts to address this confusion by documenting that
"it may be empty (or fields not propagated) if it's used for the
Image.ContainerConfig field".

Perhaps alternatives are possible (aliasing the type?) but we can
look at those in a follow-up.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
…1.41)

ContainerConfig is used in multiple locations (for example, both for
Image.Config and Image.ContainerConfig). Unfortunately, swagger does
not allow documenting individual uses if a type is used; for this type,
the content is _optional_ when used as Image.ContainerConfig (which is
set by the classic builder, which does a "commit" of a container, but
not used when building an image with BuildKit).

This patch attempts to address this confusion by documenting that
"it may be empty (or fields not propagated) if it's used for the
Image.ContainerConfig field".

Perhaps alternatives are possible (aliasing the type?) but we can
look at those in a follow-up.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
@thaJeztah thaJeztah force-pushed the api_document_ContainerConfig branch from bef6007 to 07dba5d Compare April 19, 2022 14:22
@thaJeztah
Copy link
Member Author

@tonistiigi updated; PTAL

@thaJeztah
Copy link
Member Author

Thx! Let me bring this one in

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

Successfully merging this pull request may close these issues.

2 participants