enable experimental commands by default, and remove BUILDX_EXPERIMENTAL env-var

[thaJeztah]

I saw #3240 which reminded me that I wanted to open this patch as suggestion.

remove "experimental" hint from help / usage output

This was added in 02c2073, which changed the buildx CLI to match the behavior of the docker CLI, which conditionally hid some options that were marked experimental. The CLI now shows has client-side experimental options enabled by default (but labeled as experimental where suitable).

Before this patch, every command would print this message unless experimental was enabled;

docker buildx --help
...
Run 'docker buildx COMMAND --help' for more information on a command.

Experimental commands and flags are hidden. Set BUILDX_EXPERIMENTAL=1 to show them.

With this patch applied, that message is no longer shown.

commands: enable experimental commands by default

Experimental commands are labeled as experimental, but we can enable
them by default to encourage users to try them.

remove uses of BUILDX_EXPERIMENTAL for generating docs

As the experimental commands are enabled by default now, there's
no need to set this env-var for generating the docs.

util/confutil: remove IsExperimental() utility

This function is no longer used, and does not have external
consumers; https://grep.app/search?f.lang=Go&q=.IsExperimental%28%29

tests: remove redundant cleanup

t.TempDir() already cleans up after the test.

remove "experimental" integration tests

Experimental commands are now enabled by default, so there should not
be a need to run tests separately.

docs: remove use of BUILDX_EXPERIMENTAL as example

It was only used to illustrate the concept, so let's use something
generic.

[thaJeztah]

Also considering if we should just (as we did for the CLI) always enable the debug command;

buildx/commands/root.go

Lines 121 to 123 in 08dd378

	if confutil.IsExperimental() {
	cmd.AddCommand(debugCmd(dockerCli, opts))
	}

The output already shows it's experimental;

BUILDX_EXPERIMENTAL=1 docker buildx debug --help
Usage:  docker buildx debug [OPTIONS] COMMAND

Start debugger (EXPERIMENTAL)

EXPERIMENTAL:
  docker buildx debug is an experimental feature.
  Experimental features provide early access to product functionality. These
  features may change between releases without warning, or can be removed from a
  future release. Learn more about experimental features in our documentation:
  https://docs.docker.com/go/experimental/

[crazy-max]

Also considering if we should just (as we did for the CLI) always enable the debug command

With on-going work with debug command related to new DAP implementation I think we should keep it experimental for now:

• dap: add debug adapter implementation #3235
• dap: support evaluate request to invoke a container #3257
• dap: add stack traces with next and continue functionality #3279

[thaJeztah]

Yeah, I was considering that we would have it visible, but call out that it's experimental? It may help getting more people to try it if we don't require config changes, as long as we explicitly call out that it's experimental?

[crazy-max]

In the future I agree that we should deprecate BUILDX_EXPERIMENTAL as the CLI already marks commands as experimental anyway.

[jsternberg]

For what it's worth, the debug adapter stuff is going under another command in dap. Right now, debug controls the monitor. We do potentially have plans to completely remove the debug command and integrate it directly with build.

[crazy-max]

Discussed with @tonistiigi, we would need to always enable the debug command if we are removing this hint from help so users are aware of it.

[crazy-max]

LGTM

It would also solve #2495 that I wanted to fix today and remembered your PR 😅

We should get this one in.

[thaJeztah]

Did a quick rebase to get a fresh run of CI and moved it out of draft

[thaJeztah]

All green again; PTAL

[thaJeztah]

Updated to now enable experimental commands by default;

• commands: enable experimental commands by default
• remove uses of BUILDX_EXPERIMENTAL for generating docs
• util/confutil: remove IsExperimental() utility
• remove "experimental" integration tests
• docs: remove use of BUILDX_EXPERIMENTAL as example

[thaJeztah]

Not really related, but my IDE was complaining about the unhandled error, and it was redundant, so added a commit to remove it 😂

[crazy-max]

@thaJeztah For a follow-up I was wondering if we still need to alter Usage and Short for flags and commands in:

buildx/util/cobrautil/cobrautil.go

Lines 22 to 53 in 5569825

	func MarkFlagExperimental(f *pflag.Flag) {
	if _, ok := f.Annotations[annotationExperimentalCLI]; ok {
	return
	}
	if f.Annotations == nil {
	f.Annotations = make(map[string][]string)
	}
	f.Annotations[annotationExperimentalCLI] = nil
	f.Usage += " (EXPERIMENTAL)"
	}
	func MarkFlagsExperimental(fs *pflag.FlagSet, names ...string) {
	for _, name := range names {
	f := fs.Lookup(name)
	if f == nil {
	logrus.Warningf("Unknown flag name %q", name)
	continue
	}
	MarkFlagExperimental(f)
	}
	}
	func MarkCommandExperimental(c *cobra.Command) {
	if _, ok := c.Annotations[annotationExperimentalCLI]; ok {
	return
	}
	if c.Annotations == nil {
	c.Annotations = make(map[string]string)
	}
	c.Annotations[annotationExperimentalCLI] = ""
	c.Short += " (EXPERIMENTAL)"
	}

Maybe docker/cli has this kind of helpers already?

[thaJeztah]

Maybe docker/cli has this kind of helpers already?

docker/cli adds an experimental warning to the "usage" / "help" output of the command itself, but does not add a (EXPERIMENTAL) to flags and/or commands in overviews.

We should probably look what we want to do there; to some extend the "ALL CAPS" format seems a bit aggressive, but maybe there's some middle ground.