-
Notifications
You must be signed in to change notification settings - Fork 22
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
Implement plugin-group publishing tooling with builder plugin #123
Conversation
4a87aa9
to
73d5824
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've gone through the first chunk of changes and it all makes sense.
I'm posting come comments about style or error messages and will continue the review
52adde0
to
72c9351
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes look good in general. I have some nits on the docs.
Main think I also had some issue with was the PluginIdentifier overloading and I am glad @marckhouzam pointed it out.
Implements following commands: - `tanzu builder inventory plugin-group add` - `tanzu builder inventory plugin-group activate` - `tanzu builder inventory plugin-group deactivate` The change also updates `tanzu builder plugin build` to take additional input flag `--plugin-scope-association-file`. If this flag is provided the build process will automatically generate a plugin-group-manifest.yaml file within the provided `--binary-artifacts` directory. The change also implements `InsertPluginGroup` and `UpdatePluginGroupActivationState` APIs in the plugininventory package Update `cmd/plugin/builder/README.md` with the new commands. Only install mandatory plugin using plugin group install
16182cf
to
9dbb887
Compare
This makes sense for the developer, but for the end-user, we can improve it by saying, "the plugin group with the name already exists!" |
what happens when we run |
please create an issue for E2E tests, and also add all use cases to handle as part of E2E tests. |
Yes. That is the behavior we want. However, the client-side changes for the |
Better to add some messages for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
added few comments
As mentioned above, handling the activated/deactivated state in the UX in the CLI will be handled with a separate issue. However, the goal of the deactivated state is to not even should that deactivated plugin group exist. It will only be consumed for the pre-release testing. |
I'm not sure what you really meant with this question, so I'll try to answer as I understood it.
This means the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Beautiful work @anujc25 !
I have one comment about cleaning up the temporary directory, but all the others are grammatical suggestions.
Thanks, @marckhouzam for the detailed comments on the documentation. 👍 |
ceaf39b
to
8995496
Compare
What this PR does / why we need it
Implements the following commands:
tanzu builder inventory plugin-group add
tanzu builder inventory plugin-group activate
tanzu builder inventory plugin-group deactivate
The change also updates
tanzu builder plugin build
to take additionalinput flag
--plugin-scope-association-file
. If this flag is providedthe build process will automatically generate a
plugin-group-manifest.yaml file within the provided
--binary-artifacts
directory.
The change also implements
InsertPluginGroup
andUpdatePluginGroupActivationState
APIs in the plugininventory packageUpdate
cmd/plugin/builder/README.md
with the new commands.Which issue(s) this PR fixes
Fixes #
Describe testing done for PR
Adding and verifying plugin groups:
Release note
Additional information
Special notes for your reviewer