docker
Command short description duplicated in output
$ docker buildx version
github.com/docker/buildx v0.14.1-desktop.1 5a0555e6c99a65811f4409bce8460a8fb89474f1
$ docker buildx
Extended build capabilities with BuildKit
Usage: docker buildx [OPTIONS] COMMAND
Extended build capabilities with BuildKit
Options:
--builder string Override the configured builder instance
Management Commands:
imagetools Commands to work on images in registry
Commands:
bake Build from a file
build Start a build
create Create a new builder instance
dial-stdio Proxy current stdio streams to builder instance
du Disk usage
inspect Inspect current builder instance
ls List builder instances
prune Remove build cache
rm Remove one or more builder instances
stop Stop builder instance
use Set the current builder instance
version Show buildx version information
Run 'docker buildx COMMAND --help' for more information on a command.
Experimental commands and flags are hidden. Set BUILDX_EXPERIMENTAL=1 to show them.
This first line Extended build capabilities with BuildKit should not be there.
Don't repro in standalone mode:
$ ./buildx-v0.14.1.linux-amd64
Extended build capabilities with BuildKit
Usage:
./buildx-v0.14.1.linux-amd64 [command]
Available Commands:
bake Build from a file
build Start a build
create Create a new builder instance
dial-stdio Proxy current stdio streams to builder instance
du Disk usage
help Help about any command
imagetools Commands to work on images in registry
inspect Inspect current builder instance
ls List builder instances
prune Remove build cache
rm Remove one or more builder instances
stop Stop builder instance
use Set the current builder instance
version Show buildx version information
Flags:
--builder string Override the configured builder instance
-h, --help help for ./buildx-v0.14.1.linux-amd64
Use "./buildx-v0.14.1.linux-amd64 [command] --help" for more information about a command.
Experimental commands and flags are hidden. Set BUILDX_EXPERIMENTAL=1 to show them.
I really doubt it, for hooks to fire, it must also be configured as such in config.json, and we didn't ship a configuration for Buildx w/ piñata.
I guess if it were configured, it would be possible to cause some misfiring if the plugin wasn't prepared for it, but in that case the incorrect output should be captured by the CLI and if it's not a valid hooks JSON, the CLI would ignore it. Even if it prints, it should be under the stylized "Next Steps" bit at the end, and there's no such section here
Also, looks like the standalone output already included an "Extended..." line before the "Usage:" line, so the incorrect one here is probably the one after that (and before "Options..").
There might be some issue with the help output logic though, there seems to be some special handling there since the CLI output includes extra stuff as well.
Also, looks like the standalone output already included an "Extended..." line before the "Usage:" line
Ah indeed didn't catch it was before!
Looks like Usage output currently includes the path that was used to execute;
Usage:
./buildx-v0.14.1.linux-amd64 [command]
Wondering if that's intentional (I know for --version it's not recommended to use args[0], but not sure what the general recommendation is for usage output.
Did a quick compare with docker, and that looks to have things hard-coded (but given, docker won't be executed as a plugin 😅
/usr/local/bin/docker
Usage: docker [OPTIONS] COMMAND
./build/docker-darwin-arm64
Usage: docker [OPTIONS] COMMAND