Skip to content
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

Add an info field for features like buildkit #3083

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

sudo-bmitch
Copy link
Contributor

Signed-off-by: Brandon Mitchell git@bmitch.net

- What I did

Added a client feature section to docker info to expose whether buildkit is enabled. I'm not certain this should be a map of strings, if we want an array like Plugins, hardcode a struct, or some other way to track. This would fix moby/moby#42350

- How I did it

This is using the same call from docker build --help to adjust the help message for arguments on whether buildkit is enabled.

- How to verify it

$ docker info --format '{{index .ClientInfo.Features "buildkit"}}'
enabled

$ DOCKER_BUILDKIT=0 docker info --format '{{index .ClientInfo.Features "buildkit"}}'

- Description for the changelog

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

cute cat

Signed-off-by: Brandon Mitchell <git@bmitch.net>
@@ -25,6 +25,7 @@ type infoOptions struct {
type clientInfo struct {
Debug bool
Context string
Features map[string]string
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can this be just []string?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, that's something I'm very open to. I think there are several options and I'm happy to go with any:

  1. Features map[string]string with each feature able to take a value, this could be something other than enabled for other features.
  2. Features []string and just have each feature a name. Simple and too the point.
  3. Features []feature where feature is just type feature struct { name string } today, but able to add more fields if needed in the future. This mirrors the plugin layout.
  4. Buildkit bool just hardcode a single field for buildkit, and then need another for the next feature later. This has the advantage of being easy to template with --format.

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

Successfully merging this pull request may close these issues.

Feature request: docker info output on whether buildkit is enabled
2 participants