Show homepage field post-install by default?

[corneliusweig]

Many plugins use the caveats section to show a link to their plugin repository. This means more plugin manifest review effort for us, but also for the users it's bad because there is no standard format, because every plugin is slightly different.

So what about showing the project homepage post-install by default? This is not always equivalent, because some plugins direct, for example, to a USAGE.md instead of the usual README. But even in those cases, I think its better to have a uniform layout than what we currently have.

[ahmetb]

Yeah, I think this would be a good idea.
Alternatively, we can also show how to invoke the plugin ("kubectl $NAME") as it's also repeated.

[corneliusweig]

The kubectl $NAME pattern is something I'd rather get rid off. It really doesn't add anything, because krew users should already be used to how a plugin is invoked.

For me, the only justification for this is to let users know how to get help, like kubectl $NAME --help.

[ahmetb]

krew users should already be used to how a plugin is invoked.

I am not so sure about this part. Hard to tell if people understand the plugin mechanics.

[chriskim06]

It seems like homepage is just a link to the project . Is the intention of this to replace the caveats section that gets displayed with just the homepage (and fallback to caveats if homepage is empty)?

[corneliusweig]

Not quite. The idea is to show homepage separately, so that the caveats section no longer gets (ab-)used to just show the homepage.

The caveats section should focus more on real caveats, like required dependencies or required admin rights/roles to execute the plugin.

[ahmetb]

+1 to that and we currently use homepage to infer the source repo of the project for some of the tooling (audit, analytics, auto version bumps etc) we're building.

[chriskim06]

Sounds good, did you have anything in mind for how it should be formatted? Should it follow a similar format to caveats:

Installing plugin: grep
HOMEPAGE:
\
 |  https://github.com/guessi/kubectl-grep
/
CAVEATS:
\
 |  This plugin requires an existing KUBECONFIG file, with a `current-context` field set.
 |
 |  Usage:
 |
 |    $ kubectl grep # output help messages
 |
 |  More Info:
 |  - https://github.com/guessi/kubectl-grep
/
Installed plugin: grep

[ahmetb]

First of all we should make sure these formatting messages should not show during upgrading of plugins.

I was hoping to incorporate this, too:

Alternatively, we can also show how to invoke the plugin ("kubectl $NAME") as it's also repeated.

What if we did something like this:

Installed plugin: grep
\  
 | Use this plugin:
 |     kubectl grep
 | Documentation:
 |     https://github.com/guessi/kubectl-grep
 | Caveats:
 |  \
 |   |  This plugin requires an existing KUBECONFIG file,
 |   |  with a `current-context` field set.
 |  /
/

So above I did

• created a nested section like caveats for optional reading
• nested "caveats" under that section
• moved "installed" message above this block

[chriskim06]

/assign @chriskim06

[ahmetb]

Fixed by #408.

(You can just say "Fixes #402" next time in your PR description.)
/close

[k8s-ci-robot]

@ahmetb: Closing this issue.

In response to this:

Fixed by #408.

(You can just say "Fixes #402" next time in your PR description.)
/close

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.