add top-level "docker bake" command as alias for "docker buildx bake"

[thaJeztah]

The docker buildx bake command has reached GA; this patch adds a top-level docker bake command as alias for docker buildx bake to improve discoverability and make it more convenient to use.

With this patch:

docker --help

Usage:  docker [OPTIONS] COMMAND

A self-sufficient runtime for containers

Common Commands:
  run         Create and run a new container from an image
  exec        Execute a command in a running container
  ps          List containers
  build       Build an image from a Dockerfile
  bake        Build from a file
  pull        Download an image from a registry
  push        Upload an image to a registry
  images      List images
...

The command is hidden if buildx is not installed;

docker --help
Usage:  docker [OPTIONS] COMMAND

A self-sufficient runtime for containers

Common Commands:
  run         Create and run a new container from an image
  exec        Execute a command in a running container
  ps          List containers
  build       Build an image from a Dockerfile
  pull        Download an image from a registry
  push        Upload an image to a registry
  images      List images
...

We can do some tweaking after this; currently it show an error in situations where buildx is missing. We don't account for "DOCKER_BUILDKIT=0", because this is a new feature that requires buildx, and cannot be "disabled";

buildx missing;

docker bake
ERROR: bake requires the buildx component but it is missing or broken.
       Install the buildx component to use bake:
       https://docs.docker.com/go/buildx/

BuildKit disabled:

DOCKER_BUILDKIT=0 docker bake
ERROR: bake requires the buildx component but it is missing or broken.

- Human readable description for the release notes

Add `docker bake` sub-command as alias for `docker buildx bake`

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

[codecov-commenter]

Codecov Report

❌ Patch coverage is 23.33333% with 23 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
cli/command/builder/cmd.go	0.00%	13 Missing ⚠️
cmd/docker/builder.go	50.00%	4 Missing and 2 partials ⚠️
cmd/docker/docker.go	0.00%	4 Missing ⚠️

📢 Thoughts on this report? Let us know!

[thaJeztah]

Probably something we need to improve when generating these, and have an option to specify a custom target for these (so that bake can link to https://docs.docker.com/buildx/bake.md, and attach can link to docker container attach directly).

ISTR we had this for flags, but not sure now if we had it for commands.

[crazy-max]

How does it check if buildx plugin is installed? Through aliases annotation?

[thaJeztah]

How does it check if buildx plugin is installed? Through aliases annotation?

I just tested some permutations

We can do some tweaking after this; currently it shows deprecation warnings
in situations where buildx is missing, or DOCKER_BUILDKIT=0 is set;

buildx missing;

docker bake
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
            Install the buildx component to build images with BuildKit:
            https://docs.docker.com/go/buildx/

Usage:  docker bake [OPTIONS] [TARGET...]

Build from a file

Aliases:
  docker buildx bake

BuildKit disabled:

DOCKER_BUILDKIT=0 docker bake
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
            BuildKit is currently disabled; enable it by removing the DOCKER_BUILDKIT=0
            environment-variable.

Usage:  docker bake [OPTIONS] [TARGET...]

Build from a file

Aliases:
  docker buildx bake

[thaJeztah]

@vvoland @crazy-max let me know if that looks "good enough" for a start. I will try to make some tweaks after this to make the error-message more correct, but it should be more and more of a corner-case if buildx is missing.

[crazy-max]

buildx missing;
...
BuildKit disabled:

I think this should be a noop if buildx is missing or BuildKit disabled imo as there is no possibility to fallback to legacy builder with bake. Maybe we should error out in such case?

[thaJeztah]

I think this should be a noop if buildx is missing or BuildKit disabled imo as there is no possibility to fallback to legacy builder with bake. Maybe we should error out in such case?

Yeah, I could change the stub command to return an error; the tricky bit here is that all the warnings are printed in the complex logic we have to forward to buildx; we really need to look at that code again, as it's ... complex.

cli/cmd/docker/docker.go

Line 427 in c718d3f

args, os.Args, envs, err = processAliases(dockerCli, cmd, args, os.Args)

cli/cmd/docker/builder.go

Lines 45 to 134 in c718d3f

	func processBuilder(dockerCli command.Cli, cmd *cobra.Command, args, osargs []string) ([]string, []string, []string, error) {
	var buildKitDisabled, useBuilder, useAlias bool
	var envs []string
	// check DOCKER_BUILDKIT env var is not empty
	// if it is assume we want to use the builder component
	if v := os.Getenv("DOCKER_BUILDKIT"); v != "" {
	enabled, err := strconv.ParseBool(v)
	if err != nil {
	return args, osargs, nil, fmt.Errorf("DOCKER_BUILDKIT environment variable expects boolean value: %w", err)
	}
	if !enabled {
	buildKitDisabled = true
	} else {
	useBuilder = true
	}
	}
	// if a builder alias is defined, use it instead
	// of the default one
	builderAlias := builderDefaultPlugin
	aliasMap := dockerCli.ConfigFile().Aliases
	if v, ok := aliasMap[keyBuilderAlias]; ok {
	useBuilder = true
	useAlias = true
	builderAlias = v
	}
	// is this a build that should be forwarded to the builder?
	fwargs, fwosargs, fwcmdpath, forwarded := forwardBuilder(builderAlias, args, osargs)
	if !forwarded {
	return args, osargs, nil, nil
	}
	if !useBuilder {
	// Builder is not explicitly configured as an alias for buildx.
	// Detect whether we should use BuildKit, or fallback to the
	// legacy builder.
	if si := dockerCli.ServerInfo(); si.BuildkitVersion != types.BuilderBuildKit && si.OSType == "windows" {
	// The daemon didn't advertise BuildKit as the preferred builder,
	// so use the legacy builder, which is still the default for
	// Windows / WCOW.
	return args, osargs, nil, nil
	}
	}
	if buildKitDisabled {
	// When using a Linux daemon, print a warning that the legacy builder
	// is deprecated. For Windows / WCOW, BuildKit is still experimental,
	// so we don't print this warning, even if the daemon advertised that
	// it supports BuildKit.
	if dockerCli.ServerInfo().OSType != "windows" {
	_, _ = fmt.Fprintf(dockerCli.Err(), "%s\n\n", buildkitDisabledWarning)
	}
	return args, osargs, nil, nil
	}
	// check plugin is available if cmd forwarded
	plugin, perr := pluginmanager.GetPlugin(builderAlias, dockerCli, cmd.Root())
	if perr == nil && plugin != nil {
	perr = plugin.Err
	}
	if perr != nil {
	// if builder is enforced with DOCKER_BUILDKIT=1, cmd must fail
	// if the plugin is missing or broken.
	if useBuilder {
	return args, osargs, nil, newBuilderError(buildxMissingError, perr)
	}
	// otherwise, display warning and continue
	_, _ = fmt.Fprintf(dockerCli.Err(), "%s\n\n", newBuilderError(buildxMissingWarning, perr))
	return args, osargs, nil, nil
	}
	// If build subcommand is forwarded, user would expect "docker build" to
	// always create a local docker image (default context builder). This is
	// for better backward compatibility in case where a user could switch to
	// a docker container builder with "docker buildx --use foo" which does
	// not --load by default. Also makes sure that an arbitrary builder name
	// is not being set in the command line or in the environment before
	// setting the default context and keep "buildx install" behavior if being
	// set (builder alias).
	if forwarded && !useAlias && !hasBuilderName(args, os.Environ()) {
	envs = append([]string{"BUILDX_BUILDER=" + dockerCli.CurrentContext()}, envs...)
	}
	// overwrite the command path for this plugin using the alias name.
	cmd.Annotations[metadata.CommandAnnotationPluginCommandPath] = strings.Join(append([]string{cmd.CommandPath()}, fwcmdpath...), " ")
	return fwargs, fwosargs, envs, nil
	}

[thaJeztah]

@crazy-max I pushed a temporary commit (to be squashed); to make it a hard failure; I think for this one we can ignore DOCKER_BUILDKIT=0 because it's new, and just requires buildx.

buildx missing;

docker bake
ERROR: bake requires the buildx component but it is missing or broken.
       Install the buildx component to use bake:
       https://docs.docker.com/go/buildx/

BuildKit disabled:

DOCKER_BUILDKIT=0 docker bake
ERROR: bake requires the buildx component but it is missing or broken.
       Install the buildx component to use bake:
       https://docs.docker.com/go/buildx/

Also added a check if buildx is installed to hide it from "docker --help", but maybe we shouldn't?

[crazy-max]

Yes this looks good for now

[thaJeztah]

Let me squash the commits; it's not "perfect", but we can tweak more

[thaJeztah]

LOL; thanks @robmry !

Changed this NewBakeStubComment -> NewBakeStubCommand (I blame autocorrect 😂)