Context switch - Plugin and Docker Desktop integration#1628
Context switch - Plugin and Docker Desktop integration#1628thaJeztah merged 1 commit intodocker:masterfrom
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1628 +/- ##
=========================================
- Coverage 56.1% 56.1% -0.01%
=========================================
Files 300 300
Lines 20578 20593 +15
=========================================
+ Hits 11546 11554 +8
- Misses 8202 8208 +6
- Partials 830 831 +1 |
ijc
left a comment
There was a problem hiding this comment.
Some pretty minor docs nits, but otherwise looks good from the plugins PoV, thanks for taking care of this?
|
Thanks for spotting the missing exported symbols, fixed |
|
(Copying this from #1519 (review)); The concern I have with exporting all of these is that;
For the underlying code on the other hand, we have various interfaces defined; if those are lacking functionality that's needed, should we review those interfaces, and make that the API to use? |
|
Ok, I will try to move name validation and default context handling lower in the stack then |
I don't think that dichotomy really exists as strongly as you have stated it, it is entirely valid for software to export an API which is explicitly unstable if the maintainers choose to do so and for them to then feel no qualms about changing it as necessary despite it being exported. I think that would be an entirely valid approach to consider for something like |
|
Ah, sorry, I saw the comment on the other PR first, so let me copy my reply from there (#1519 (comment));
I'm ok with this change, but we should add that note somewhere (separately from this PR), and start thinking of what changes would be needed to have a slightly higher-level interface than the API-client (to make it better consumable), but "lower" than the current functions (which, I think, are too tightly coupled to the CLI itself and the UX it has). |
cli/command/cli.go
Outdated
| // ContextStoreConfig contains the config used by the context store | ||
| // A plugin's init function may modify it to define other typed endpoint metadata by calling | ||
| // ContextStoreConfig.SetEndpoint() | ||
| var ContextStoreConfig = store.NewConfig( |
There was a problem hiding this comment.
Wouldn't it better to have a function here ?
There was a problem hiding this comment.
(to be used from outside)
There was a problem hiding this comment.
something like command.SetContextStoreEndpointType() ?
|
As discussed privately with @vdemeester, I'll wait for Silvin's pr to land and introduce a |
❤️ even better! |
67f15ee to
64d01ca
Compare
|
@thaJeztah done! PTAL :) |
|
@vdemeester WDYT? |
thaJeztah
left a comment
There was a problem hiding this comment.
changes LGTM; can you squash commits?
This will allow plugins to have custom typed endpoints, as well as create/remove/update contexts with the exact same results as the main CLI (thinking of things like `docker ee login https://my-ucp-server --context ucp-prod)` Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
64d01ca to
3126920
Compare
|
@thaJeztah rebased + squashed, thanks |
- What I did
- How I did it
- How to verify it
ping @ijc for the plugin related part
ping @gtardif @pgayvallet @guillaumerose @ebriney for the Docker Desktop part