-
Notifications
You must be signed in to change notification settings - Fork 261
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
[WIP] Kn plugins implementation #177
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: maximilien If they are not already assigned, you can assign the PR to them by writing The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@sixolet and @cppforlife this is WIP so as to avoid one HUGE PR once we have complete agreement on the plugins docs. However, for those who want to try, this can be used and is rebased on current master:HEAD. To test this PR. After building # assuming the 'kn' executable is built with this PR and in current dir
echo '#!/bin/bash
echo "Hello Knative, I am a Kn plugin"' > kn-hello
"
chmod +x kn-hello
mv kn-hello /usr/local/bin
# you can now list plugins
./kn plugin list
The following compatible plugins are available:
/usr/local/bin/kn-hello
# you can execute the 'kn-hello' plugin with
./kn hello
Hello Knative, I am a Kn plugin I will be adding unit tests and integration tests next. |
|
||
``` | ||
-h, --help help for list | ||
--name-only If true, display only the binary name of each plugin, rather than its full path |
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 think this should be reversed. In most cases I don't think people will care where the exe lives and when they do care it's probably because they're debugging to see why things are not acting correctly.
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.
OK, up for debate. Especially if we decide to have a fix location.
} | ||
|
||
if isFirstFile { | ||
fmt.Fprintf(o.ErrOut, "The following compatible plugins are available:\n\n") |
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.
this should go to stdout, not stderr
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.
Fair.
} | ||
|
||
if !pluginsFound { | ||
pluginErrors = append(pluginErrors, fmt.Errorf("error: unable to find any kubectl plugins in your PATH")) |
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.
"No plugins" shouldn't be considered an error - it's a valid state.
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.
Fair.
To prepare for the world where we consider helping the user install plugins suggested by their server, I think I'm a lot more interested in there being a configurable plugin dir (remember when we removed If we go with "anywhere on $PATH", then we have no place to install to, and also the user doesn't have independent control of what's on their PATH and what is a plugin, which bothers me somewhere in my aesthetics brain. |
Yup. Thought of that too.
I personally don’t care. Product folks might have strong opinions. Anyhow, let’s decide next call and move forward. Best. |
@duglin, first off, thanks for feedback. However, I think it’s worth re-iterating two points globally before I address each of your comments:
So you should expect this is not end game and that it looks and feels like I wanted this to be a baseline so when we decide to deviate from |
yeah, but WIP or not, I think the suggested edits are valid |
So there's good news and bad news. 👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there. 😕 The bad news is that it appears that one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request. Note to project maintainer: This is a terminal state, meaning the ℹ️ Googlers: Go here for more info. |
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
The following is the coverage report on pkg/.
|
@@ -62,10 +95,17 @@ Eventing: Manage event subscriptions and channels. Connect up event sources.`, | |||
if p.Output != nil { | |||
rootCmd.SetOutput(p.Output) | |||
} | |||
rootCmd.PersistentFlags().StringVar(&commands.CfgFile, "config", "", "config file (default is $HOME/.kn/config.yaml)") | |||
rootCmd.PersistentFlags().StringVar(&commands.PluginDir, "plugin-dir", "", "kn plugin directory (default is value in kn config or $PATH)") | |||
rootCmd.PersistentFlags().StringVar(&commands.KubeCfgFile, "kubeconfig", "", "kubectl config file (default is $HOME/.kube/config)") |
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.
Hi, @sixolet, see this version of root.go
Still need to rebase and clean up, so still WIP. However, this is where I am adding the plugin-dir
persistent flag and reading from kn's config (if exist) and defaulting to $PATH
.
I am in middle of now using this in the plugin commands. Will finish this tomorrow. But at least let's make sure we are in sync. Let me know your thoughts if you get to read this otherwise, look for next update.
Cheers 🍻
OK I need to rebase. Will try to find time to do so today. |
Implements Kn plugins re-using some code from kubectl plugins. This is WIP to allow concrete discussions and testing and hopefully also allow sub tasks to be created and worked on in parallel. This version contains the following: 1. wraps the main root Kn command to support plugin 2. plugins are any executable in PATH with name kn-* 3. 'kn plugins list' to list found kn plugins 4. skips any kn plugins found with name that match core commands, e.g., kn-service would be ignored 5. execute any valid kn plugins found 6. UTs for plugin and plugin list commands And is missing: 1. integration tests 2. plugin install command 3. plugin repository command 4. plugin / Knative server version negotiation 5. anything else we agree on in plugin req doc
@maximilien: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
OK finally getting a chance to go back to this as I am wrapping up my trip in Beijing 🇨🇳 Will work on rebasing with latest updates and also move all tests to |
Closing this one since #249 is the first non-WIP version. Please review that one. |
Implements Kn plugins re-using some code from kubectl plugins.
This is WIP to allow concrete discussions and testing and
hopefully also allow sub tasks to be created and worked on
in parallel.
This version contains the following:
commands, e.g., kn-service would be ignored
And is missing: