-
Notifications
You must be signed in to change notification settings - Fork 18.8k
api: improve documentation of ContainerConfig type #43461
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
api: improve documentation of ContainerConfig type #43461
Conversation
d497652
to
bef6007
Compare
@tonistiigi PTAL |
api/types/types.go
Outdated
@@ -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 |
There was a problem hiding this comment.
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>
bef6007
to
07dba5d
Compare
@tonistiigi updated; PTAL |
Thx! Let me bring this one in |
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)