cmd: support cli environment variables in standalone mode

[crazy-max]

fixes #3081

In plugin mode

buildx/cmd/buildx/main.go

Lines 67 to 71 in 8efc528

	return plugin.RunPlugin(cmd, rootCmd, metadata.Metadata{
	SchemaVersion: "0.1.0",
	Vendor: "Docker Inc.",
	Version: version.Version,
	})

plugin.RunPlugin sets plugin root command through cli.SetupPluginRootCommand(cmd): https://github.com/docker/cli/blob/58fba25b0935586eb14aa6b20b936cfc26df7a19/cli-plugins/plugin/plugin.go#L164

Which calls options.InstallFlags: https://github.com/docker/cli/blob/58fba25b0935586eb14aa6b20b936cfc26df7a19/cli/cobra.go#L22C6-L24 after NewClientOptions().

We need to do the same in standalone mode so cli environment variables are supported.

[thaJeztah]

Slightly wondering what the most correct approach would be here. Ultimately this is one of the issues we discussed at some point when the cli plugins were created (i.e., ideally, the CLI ('host') would be able to handle the connection, and plugins to be able to use that connection.

The tricky bit here is that we start to (more, and more) cli-plugins to take over env-vars (and options) that are basically owned by the CLI, which also means that the CLI won't be able to change meaning for its own env-vars, without all plugins that exist to also update accordingly.

Does buildx, when running standalone, have top-level flags to specify tis-config etc? i.e., would compose be able to;

• load the context, or other env-vars
• set the correct, buildx-standalone-specific command-line options to make it set the right connection?

[crazy-max]

Thanks for your feedback, I was keeping this one in draft because I got questions related to these changes so I'm glad you came up here 😅

Does buildx, when running standalone, have top-level flags to specify tis-config etc? i.e., would compose be able to;

No, buildx does not have any top-level flags to set tls-config but I would assume that env vars like DOCKER_TLS, DOCKER_CERT_PATH would still be handled by docker/cli when running in standalone mode similar to plugin one. Maybe that's something that cli.Initialize should support in https://github.com/docker/cli/blob/58fba25b0935586eb14aa6b20b936cfc26df7a19/cli/command/cli.go#L234?

[tonistiigi]

I'm confused what is docker-specific in this InstallFlags call? And if there is nothing docker-specific and just needs to be called then why isn't NewClientOptions() handling it automatically.

[crazy-max]

just needs to be called then why isn't NewClientOptions() handling it automatically.

Yes it would be better if this was handled directly in docker/cli.

[tonistiigi]

Or is the difference from calling this function in PersistentPreRunE instead of before NewRootCmd()?

Anyway, if this is better in cli, make a tracking issue for it there.

[crazy-max]

Or is the difference from calling this function in PersistentPreRunE instead of before NewRootCmd()?

No there isn't but I was hoping to be able to use options.InstallFlags(cmd.Flags()) here but it panics because we already declare a global debug flag.

[tonistiigi]

Or is the difference from calling this function in PersistentPreRunE instead of before NewRootCmd()?

Anyway, if this is better in cli, make a tracking issue for it there.