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

cli-plugins: add concept of experimental plugin, only enabled in experimental mode #1898

Merged
merged 2 commits into from
May 23, 2019

Conversation

tiborvass
Copy link
Collaborator

@tiborvass tiborvass commented May 21, 2019

Closes: #1897

To test, add $(pwd)/build/plugins-linux-amd64 to "cliPluginsExtraDirs" config and run:

make plugins
make binary
HELLO_EXPERIMENTAL=1 docker helloworld

To show it enabled:

HELLO_EXPERIMENTAL=1 DOCKER_CLI_EXPERIMENTAL=enabled docker helloworld

Signed-off-by: Tibor Vass tibor@docker.com

@cpuguy83
Copy link
Collaborator

Not sure I understand the plugin code specifically.
I would expect a plugin would be told if experimental mode is enabled or not and let it decide how to handle it?

@tiborvass
Copy link
Collaborator Author

@cpuguy83 Hmm, didn't think of that but it sounds weird to me. It'd be functionally the same though: in both cases the plugin decides whether it is experimental or not, in one case it is through a metadata field, the other would be through code.

The idea in the current PR is that if experimental is off on the cli, we do not consider experimental plugins.

@codecov-io
Copy link

Codecov Report

Merging #1898 into master will decrease coverage by <.01%.
The diff coverage is 35.29%.

@@            Coverage Diff             @@
##           master    #1898      +/-   ##
==========================================
- Coverage   56.75%   56.74%   -0.01%     
==========================================
  Files         309      309              
  Lines       21680    21692      +12     
==========================================
+ Hits        12305    12310       +5     
- Misses       8476     8482       +6     
- Partials      899      900       +1

@cpuguy83
Copy link
Collaborator

What if a plugin has some experimental functionality but is not wholly experimental?

@cpuguy83
Copy link
Collaborator

I guess it's ok to have a plugin which is entirely experimental and not list it at all if so.

@@ -48,7 +49,7 @@ func TestValidateCandidate(t *testing.T) {
},
})

for _, tc := range []struct {
for i, tc := range []struct {
Copy link
Collaborator

Choose a reason for hiding this comment

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

It'd be really nice to give these test cases a name and use t.Run.
Debugging with an index like this is painful.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Exactly what i was struggling with, hence the i that i wanted to remove.

@tiborvass
Copy link
Collaborator Author

@cpuguy83 added test names in a separate commit.

Copy link
Collaborator

@cpuguy83 cpuguy83 left a comment

Choose a reason for hiding this comment

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

Is there a way to make a negative test, i.e. experimental plugin without experimental mode?

@tiborvass
Copy link
Collaborator Author

tiborvass commented May 22, 2019

@cpuguy83 it's part of the tests. The test case is experimental required.

@cpuguy83
Copy link
Collaborator

My bad! Overlooked it.

Copy link
Collaborator

@cpuguy83 cpuguy83 left a comment

Choose a reason for hiding this comment

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

LGTM

@@ -33,7 +33,9 @@ type Plugin struct {
// is set, and is always a `pluginError`, but the `Plugin` is still
// returned with no error. An error is only returned due to a
// non-recoverable error.
func newPlugin(c Candidate, rootcmd *cobra.Command) (Plugin, error) {
//
// nolint: gocyclo
Copy link
Contributor

Choose a reason for hiding this comment

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

Can be done in a follow-up, but I think this function should be split into pieces as it reached the go-cyclo threshold.

@ijc
Copy link
Contributor

ijc commented May 22, 2019

Actual code changes look fine to me. I'd suggest adding some variants to the tests under e2e/cli-plugins/ to ensure that the experimental plugins appear in the right places at the right time wrt the various variations on docker help docker --help, in particular I think we want to avoid having to have people remember to rerun the test suit with the envvar set and the help/--help stuff has been tricky to get right.

Or maybe rather than just doubling ~every test in that suite just add another stunt plugin as e2e/cli-plugins/experimental (using e2e/cli-plugins/plugins/nopersistentprerun as the ~simplest template rather than the hello one) and then update the various golden files to accommodate that showing up in the various places it will show up. That will mean splitting some of the *.golden files into two versions and conditionally adding -experimental to the filename in the golden.Assert() calls (perhaps best done with a helper/wrapper?)

Even with the stunt plugin I think you want a new case which does docker experimental help and docker help experimental (given the stunt plugin is docker-experimental) since that presumably needs to DTRT...

Copy link
Contributor

@silvin-lubecki silvin-lubecki left a comment

Choose a reason for hiding this comment

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

LGTM with small comments fixed 👍

cli-plugins/manager/manager.go Outdated Show resolved Hide resolved
@silvin-lubecki
Copy link
Contributor

Linter is complaining

cli-plugins/manager/candidate_test.go:76:157:warning: unknown field allowExperimental in struct literal (gosimple)
cli/command/formatter/reflect_test.go:15:34:warning: nolint directive did not match any issue (nolint)
cli-plugins/manager/candidate_test.go:76:157:warning: unknown field allowExperimental in struct literal (unused)

@silvin-lubecki
Copy link
Contributor

Some tests are failing:

# github.com/docker/cli/cli-plugins/manager [github.com/docker/cli/cli-plugins/manager.test]
cli-plugins/manager/candidate_test.go:76:157: unknown field 'allowExperimental' in struct literal of type struct { name string; c *fakeCandidate; err string; invalid string }
cli-plugins/manager/candidate_test.go:77:127: unknown field 'allowExperimental' in struct literal of type struct { name string; c *fakeCandidate; err string; invalid string }

@tiborvass
Copy link
Collaborator Author

@silvin-lubecki fixed. @ijc thanks for the pointers, I'll do that in a follow up.

Tibor Vass added 2 commits May 22, 2019 15:35
…rimental mode

To test, add $(pwd)/build/plugins-linux-amd64 to "cliPluginsExtraDirs" config and run:
make plugins
make binary
HELLO_EXPERIMENTAL=1 docker helloworld

To show it enabled:
HELLO_EXPERIMENTAL=1 DOCKER_CLI_EXPERIMENTAL=enabled docker helloworld

Signed-off-by: Tibor Vass <tibor@docker.com>
Signed-off-by: Tibor Vass <tibor@docker.com>
@silvin-lubecki
Copy link
Contributor

ping @thaJeztah

@tonistiigi
Copy link
Member

To me, it makes much more sense if there is a separate experimental directory (or a naming scheme) for experimental plugins instead of a metadata command.

Plugins have their own versioning/revisions that clearly shows in the output. Eg. I have no desire to mark buildx experimental. If you build it or pull a binary from github there is no need to punish the user so that they need to get all the other experimental things as well and use environment the few other users are using. Adding a plugin does not make the rest of the docker experience more unstable and having buildx with its 0.x version needing to modify the configuration while a random hello-world plugin does not, does not make sense. In practice, this means that people would just start to call buildx directly and not install it as a plugin at all, leading to fragmentation.

Things are different when a plugin is deployed together with Docker CE/EE suites and has a different compatibility guarantees. Then it does makes sense to not enable them automatically. And for that these suites should install the plugins in a way that only enables them when the global experimental mode is on. Eg. by putting them in a separate directory where cli looks for them or naming them docker-buildx-experimental.

@andrewhsu
Copy link
Contributor

Talked with @tonistiigi about his #1898 (comment) and i've updated the issue proposal for change request with details on the implementation #1897 (comment) to accommodate for a user installing a plugin explicitly. cc @tiborvass

@tiborvass
Copy link
Collaborator Author

I opened #1902.

@tiborvass tiborvass closed this May 23, 2019
@tiborvass tiborvass reopened this May 23, 2019
@tiborvass
Copy link
Collaborator Author

I think @tonistiigi's points are valid and we should still consider the alternative I opened in #1902, but it turns out it requires more work on Desktop and it's blocking an RC release, so I'm advocating for merging this to unblock.

Copy link
Contributor

@andrewhsu andrewhsu left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

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

LGTM

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

Successfully merging this pull request may close these issues.

docker cli experimental flag for plugins
10 participants