Closed toolmantim closed 6 years ago
This does assume though that the name
in plugin.yml matches the repo name. So it wouldn't allow for the name to be Docker Compose
for example.
These are the current names of the plugins (some wouldn't validate):
The community plugins look very consistent:
I think the linter's --name
argument is incorrectly named.
@keithpitt @lox do you reckon we should standardise on having the plugin.yml name
entry match the repo slug, as per the community plugins and most of our plugins as they are now, or go for plain English names instead?
Whatever one we choose, people will follow by example, which is I think what's happened so far. I think plain English is better for a future plugin directory?
If we go with plain English ones, I'll change the plugin-linter's --name
argument to --id
instead, or whatever word we used to refer to the my-org/my-plugin
part of this:
steps:
- plugins:
my-org/my-plugin#v1.0.0: ~
Unrelated: it'd be great to add tags
or topics
to the plugin.yml, so in the future we can slice and browse plugins by tags
https://probot.github.io/apps/ is a nice example of a simple plugin directory. I'm 99% certain we want plain English for the name
field in plugin.yml now.
@toolmantim yeah, I agree. I think plugin id
is a good differentiator. I wouldn't want repo name to == plugin name since you'd get into all sorts of issues with repo name changes, and repos with multiple plugins in them.
Alright, all of our own plugins have been updated.
PRs have been sent for some of the community plugins:
Still to come:
Ok, all done!
Tt should be unnecessary to configure the linter with
--name
just so it can search the readme forplugins: ${name}#v.*
code blocks, because it's already set in the plugin.yml file. It'll need to handle the org scoping tho, which is currently done via the--name
linter argument.