cli-plugins: add concept of experimental plugin, only enabled in experimental mode#1898
Conversation
d0c799b to
fd85a6f
Compare
|
Not sure I understand the plugin code specifically. |
|
@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. |
fd85a6f to
c483c63
Compare
Codecov Report
@@ 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 |
|
What if a plugin has some experimental functionality but is not wholly experimental? |
|
I guess it's ok to have a plugin which is entirely experimental and not list it at all if so. |
| }) | ||
|
|
||
| for _, tc := range []struct { | ||
| for i, tc := range []struct { |
There was a problem hiding this comment.
It'd be really nice to give these test cases a name and use t.Run.
Debugging with an index like this is painful.
There was a problem hiding this comment.
Exactly what i was struggling with, hence the i that i wanted to remove.
c483c63 to
10b899b
Compare
|
@cpuguy83 added test names in a separate commit. |
caba26d to
8711e0f
Compare
cpuguy83
left a comment
There was a problem hiding this comment.
Is there a way to make a negative test, i.e. experimental plugin without experimental mode?
|
@cpuguy83 it's part of the tests. The test case is |
|
My bad! Overlooked it. |
8711e0f to
0155e5b
Compare
| // non-recoverable error. | ||
| func newPlugin(c Candidate, rootcmd *cobra.Command) (Plugin, error) { | ||
| // | ||
| // nolint: gocyclo |
There was a problem hiding this comment.
Can be done in a follow-up, but I think this function should be split into pieces as it reached the go-cyclo threshold.
|
Actual code changes look fine to me. I'd suggest adding some variants to the tests under Or maybe rather than just doubling ~every test in that suite just add another stunt plugin as Even with the stunt plugin I think you want a new case which does |
silvin-lubecki
left a comment
There was a problem hiding this comment.
LGTM with small comments fixed 👍
|
Linter is complaining |
|
Some tests are failing: |
0155e5b to
49c6dbe
Compare
|
@silvin-lubecki fixed. @ijc thanks for the pointers, I'll do that in a follow up. |
…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>
49c6dbe to
bb8e89b
Compare
|
ping @thaJeztah |
|
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 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 |
|
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 |
|
I opened #1902. |
|
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. |
Closes: #1897
To test, add $(pwd)/build/plugins-linux-amd64 to "cliPluginsExtraDirs" config and run:
To show it enabled:
Signed-off-by: Tibor Vass tibor@docker.com