The documentation for the community.general.jenkins_plugin module describes the “name” parameter as simply “Plugin name”.
The examples in the documentation show the values to be lowercase and hyphenated.
I’m assuming that simply writing the name of the plugin as a string (e.g.: "Role-based Authorization Strategy"), as seen in Jenkins Plugin Index, isn’t going to work. Where exactly can I get those valid names of the plugins as shown in the examples?
Try this:
$ curl -L https://updates.jenkins.io/current/plugin-versions.json \
| jq '.plugins | keys'
[Edit: I’m guessing the one for “Role-based Authorization Strategy” is “role-strategy”.]
That command seems to give a list of unique plugin names that look similar to what the Ansible module wants. But how do I know which name belongs to which plugin? I have no idea which of those is for the “Role-based Authorization Strategy” plugin.
How is a new Ansible user supposed to reliably find the correct plugin name for the module’s syntax? That’s the question I got when reading the doc.
When I hover over the Role-based Authorization Strategy (or any other) plugin link in my Jenkins
https://jenkins.example.com/manage/pluginManager/installed or
https://jenkins.example.com/manage/pluginManager/available pages, my browser shows the down-cased short name as the link target.
Like you, I was surprised the “presentation name” so to speak title wasn’t in the json. 
Edit: The relationship between the title and the short name is contained in the slightly invalid json page
https://updates.jenkins.io/update-center.json.
Yes, I’ve seen that, Jenkins refers to it as “plugin ID”. However, this means that I, or a new user, will have to access an existing Jenkins server to find plugin ID. I was expecting to write a playbook to automate configuring Jenkins, before I even login to the server for the first time.
My problem is that Ansible docs don’t specify exactly where I can get this plugin ID, and it also doesn’t help that the parameter is called “name”. I just need to know what is the method recommended by Ansible or the module’s creators to get that unique name or ID.
It’s in https://updates.jenkins.io/update-center.json, you just have to dig it out.
The shell pipeline below will give you a list of (name,title) pairs. The valid json data comes after the first line and before the last line of the curl output, so you have to play funny head/tail (or sed) games to throw away the non-json parts. The final jq expression creates a list of dicts from fields extracted from the plugins list in that json.
$ curl -s -L https://updates.jenkins.io/update-center.json \
| head -n -1 \
| tail -n 1 \
| jq '[.plugins[] | {name: .name, title: .title}]'
The output looks like this:
[
{
"name": "42crunch-security-audit",
"title": "42Crunch REST API Static Security Testing"
},
{
"name": "AnchorChain",
"title": "AnchorChain"
},
{
"name": "ApicaLoadtest",
"title": "Apica Loadtest"
},
{
"name": "BlameSubversion",
"title": "Blame Subversion"
},
…
{
"name": "role-strategy",
"title": "Role-based Authorization Strategy"
},
…
{
"name": "zulip",
"title": "Zulip"
}
]
This isn’t documented in the jenkins_plugin docs.
(There are currently 2081 plugins in that data!)
I’m not saying that Ansible should document all the Jenkins plugins, that’s Jenkins’ job. I’m saying that the Ansible docs should mention at least something about where to get those unique names/IDs.
How will someone, who’s never used this Ansible module, know that they have to parse and filter through Jenkins’ update repository for this?
I, myself, couldn’t find the source of these names/IDs in the docs, so I’m asking here. It’s like asking for the available data-types of a programming language because the docs didn’t mention those.
Also, if the JSON file is the intended method, it means that writing the playbook requires a tool to read the JSON, which must be mentioned in the docs. Not to mention, the method seems crude and inelegant.
The latest version of the doc only says
…should be in the same format as the one provided by Jenkins update center (https://updates.jenkins.io/current/plugin-versions.json)
and doesn’t make it clear where these strings come from, as you say.
I think you just answered your own question! And, yeah, it’s not a great look.
It is a community.general module. Until some community member who is annoyed enough by the situation submits changes via a pull request, it isn’t likely to improve. Not to put work on your plate, but I don’t know any more likely candidates. 
Agreed. [sigh] Having a url which promises update-center.json but delivers invalid json introduces some crudeness, and it requires even more crudeness to restore usefulness. Even then, how is a user supposed to crawl through 2000+ plugins and have a clue which ones are actually needed? Good luck putting an interface on that.
Your quote from the doc is from a point specifying how a custom update link should be configured. It doesn’t explicitly state where to get the unique plugin names.
I actually found that the unique name/ID are mentioned in the respective plugin’s page and URL.
While I’m more confused than annoyed, you’re correct about submitting a PR for this community plugin. Since I’m new to Jenkins, I need to confirm with them if the ID on the page is consistently the same as the ones in the JSON or URL. If I get a confirmation, I will use that to raise a PR.
Thanks for all the information you provided!
I asked in the Jenkins Community forum if the unique IDs in the update-center.json and plugin-versions.json are identical to their respective URL slugs and plugin ID mentioned in the plugin index.
I got the following answers:
Quote from Style Guide for Publishing Plugins
A plugin’s artifact ID is used as the file base name and to uniquely identify the plugin in Jenkins and on update sites.
artifact-id” in the source code and it’s also used to generate the URL of the plugin’s page.
Jenkins Update Center source code
I will use these references to raise an Issue and see where it goes.
@tukykarmakar once you work this out, perhaps you could raise a PR to improve the documentation.
@utoddl thanks for all the guidance
I have raised an issue for now. I will proceed based on the discussion there.
PR #12290 has been merged for clarifying where to get the unique plugin IDs. It should be visible in the public docs within few weeks.