Raise the bar for module `DOCUMENTAION`
This validator update was used to find the issues in https://github.com/ansible/ansible/pull/22297/files
**Validation**
* Updated Validation and docs to enforce more (items fixed in https://github.com/ansible/ansible/pull/22297/files)
* Use `suboptions` to document complex options
* Validate module name
* Validate deprecated modules have correct ANSIBLE_METADATA
**Module Documentation Generation**
* Document `suboptions:` Example https://gist.github.com/gundalow/4bdc3669d696268328ccc18528cc6718
* Tidy up HTML generation (valid HTML, no empty lists, etc)
**Documentation**
* Clarify the steps for deprecating a module
* Use correct RST headings
* Document `suboptions:` (options)
* Document `contains:` (returns)
**Details**
The aim is to get this (and corresponding module updates) complete by the time `devel` becomes `2.4`, as this allows us to raise the bar for new modules
Example `suboptions` https://gist.github.com/gundalow/4bdc3669d696268328ccc18528cc6718
The aim is to get this PR integrated into `devel` *before* we branch `stable-2.3`, this will allows us to:
* Raise the bar for new modules in 2.4
* Ensure the generated module documentation for 2.3 and higher is improved, important as we will be doing versioned docs moving forward.
can be included in Ansible, but modules (just due to the programming
@ -14,8 +15,9 @@ gives them slightly higher development priority (though they'll work in exactly
.. formerly marked with _module_dev_testing:
------------------------------
Contributing Modules Checklist
``````````````````````````````
------------------------------
The following checklist items are important guidelines for people who want to contribute to the development of modules to Ansible on GitHub. Please read the guidelines before you submit your PR/proposal.
@ -133,7 +135,7 @@ The complete module metadata specification is here: https://github.com/ansible/p
like :envvar:`API_USERNAME` would conflict between modules.
Windows modules checklist
`````````````````````````
=========================
* Favour native powershell and .net ways of doing things over calls to COM libraries or calls to native executables which may or may not be present in all versions of Windows
* modules are in powershell (.ps1 files) but the docs reside in same name python file (.py)
* look at ansible/lib/ansible/module_utils/powershell.ps1 for common code, avoid duplication
@ -158,7 +160,7 @@ To parse all arguments into a variable modules generally use:
$params = Parse-Args $args
Arguments
+++++++++
---------
* Try and use state present and state absent like other modules
* You need to check that all your mandatory args are present. You can do this using the builtin Get-AnsibleParam function.
@ -175,7 +177,7 @@ Required arguments with name validation:
@ -143,9 +143,13 @@ The following fields can be used and are all required unless specified otherwise
This is a `string`, and not a float, i.e. ``version_added: "2.1"``
:author:
Name of the module author in the form ``First Last (@GitHubID)``. Use a multi-line list if there is more than one author.
:deprecated:
If this module is deprecated, detail when that happened, and what to use instead, e.g.
`Deprecated in 2.3. Use M(whatmoduletouseinstead) instead.`
Ensure `CHANGELOG.md` is updated to reflect this.
:options:
One per module argument:
:option-name:
* Declarative operation (not CRUD)–this makes it easy for a user not to care what the existing state is, just about the final state, for example `online:`, rather than `is_online:`.
@ -155,7 +159,6 @@ The following fields can be used and are all required unless specified otherwise
* Detailed explanation of what this option does. It should be written in full sentences.
* Should not list the options values (that's what ``choices:`` is for, though it should explain `what` the values do if they aren't obvious.
* If an argument takes both True)/False and Yes)/No, the documentation should use True and False.
* If an optional parameter is sometimes required this need to be reflected in the documentation, e.g. "Required when I(state=present)."
* Mutually exclusive options must be documented as the final sentence on each of the options.
:required:
@ -167,14 +170,18 @@ The following fields can be used and are all required unless specified otherwise
* The default option must not be listed as part of the description.
:choices:
List of option values. Should be absent if empty.
:type:
If an argument is ``type='bool'``, this field should be set to ``type: bool`` and no ``choices`` should be specified.
:aliases:
List of option name aliases; generally not needed.
:version_added:
Only needed if this option was extended after initial Ansible release, i.e. this is greater than the top level `version_added` field.
This is a string, and not a float, i.e. ``version_added: "2.3"``.
:requirements:
List of requirements, and minimum versions (if applicable)
:notes:
:suboptions:
If this option takes a dict, you can define it here. See `azure_rm_securitygroup`, `os_ironic_node` for examples.
:requirements:
List of requirements, and minimum versions (if applicable)
:notes:
Details of any important information that doesn't fit in one of the above sections; for example if ``check_mode`` isn't supported, or a link to external documentation.
@ -182,8 +189,6 @@ The following fields can be used and are all required unless specified otherwise
- The above fields are are all in lowercase.
- There is no need to document the ``type:`` of an option.
- If the module doesn't doesn't have any options (for example, it's a ``_facts`` module), you can use ``options: {}``.
EXAMPLES block
@ -216,6 +221,41 @@ The RETURN section documents what the module returns, and is required for all ne
For each value returned, provide a ``description``, in what circumstances the value is ``returned``,
the ``type`` of the value and a ``sample``. For example, from the ``copy`` module::
The following fields can be used and are all required unless specified otherwise.
:return name:
Name of the returned field.
:description:
Detailed description of what this value represents.
:returned:
When this value is returned, such as `always`, on `success`, `always`
:type:
Data type
:sample:
One or more examples.
:contains:
Optional, if you set `type: complex` you can detail the dictionary here by repeating the above elements.
:return name:
One per return
:description:
Detailed description of what this value represents.
:returned:
When this value is returned, such as `always`, on `success`, `always`
:type:
Data type
:sample:
One or more examples.
For complex nested returns type can be specified as ``type: complex``.
Example::
RETURN = '''
dest:
description: destination file/path
@ -233,7 +273,7 @@ the ``type`` of the value and a ``sample``. For example, from the ``copy`` modu