api: improve documentation of ContainerConfig type#43461
Merged
thaJeztah merged 2 commits intomoby:masterfrom Apr 20, 2022
Merged
api: improve documentation of ContainerConfig type#43461thaJeztah merged 2 commits intomoby:masterfrom
thaJeztah merged 2 commits intomoby:masterfrom
Conversation
d497652 to
bef6007
Compare
Member
Author
|
@tonistiigi PTAL |
tonistiigi
reviewed
Apr 6, 2022
api/types/types.go
Outdated
| // ContainerConfig is the configuration of the container that was committed | ||
| // into the image. | ||
| // | ||
| // Depending on how the image was created, ContainerConfig, or its fields |
Member
There was a problem hiding this comment.
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
Member
Author
|
@tonistiigi updated; PTAL |
tonistiigi
approved these changes
Apr 20, 2022
Member
Author
|
Thx! Let me bring this one in |
This was referenced Nov 13, 2023
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
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)