There should no longer be a need for boto documentation - it
just adds significant extra clutter to the guidelines.
AnsibleAWSModule greatly improves the codebase to such an extent
that we should mandate it for new code unless there is a
documented good reason.
* Update doc of AnsibleAWSModule to remove incorrect connect example.
Current example uses aws_connect method which no longer exists. Replace
this with the client and resource methods that do exist.
Also remove try/except block in connect example as guidelines imply that
there aren't connection errors thrown on connection, just when later
sing the connection.
* Update AWS module guidelines to include the AnsibleAWSModule connection methods.
* Add information on integration testing to the AWS module guidelines.
* Add information on common documentation fragments to AWS module
Guidelines.
* Changes as requested on PR.
* Restructure connection section to start with current best practice
* Explain the use of the CI build groups
* Use YAML Anchors for aws credentials example
* Replace guidance on use of test groups with link to aliases file.
This achieves the goal of explaining why this file is necessary without
introducing overhead of keeping documentation up to date when test
groups change.
* Clean up vmware BOTMETA
This removes everything that's already part of the module docs. So
basically the BOTMETA file only extends the information from the module.
* Updated author information and copyright statement
* Adds the ability to override the doc build output from the command line.
* For safety, removed straight rm of BUILDDIR and removed subdirectories instead.
* Added check to see if BUILDDIR was defined to main makefile
The examples comment said 'Add a line to a file if it does not exist, without passing regexp' which suggests, that the file is being created. But the default for 'create' is false. Thus the example lacked this option.
* Automatically stuff reference in commit message
So we probably want to track which edits were performed through the
Github interface, and this change automatically adds a label to the
commit message.
```yaml
<!--- Your description here -->
+label: docsite_pr
```
Eventually this allows to (on regular basis) list the changes from
documentation readers and process them in a separate process.
So I am still not satisfied with how required parameters are being
displayed (before it was yes/no, then it became required/optional, and
only required).
Now it will display in small green 'required' under the parameter name.
This is more convenient, and provides more room for the description.
Especially on smaller screens.
So people reading the module documentation usually look for parameters
first, and are interested in examples. However the notes are at the very
end even below the Return Values (the least interesting part).
So this change moves the notes higher up, below parameters, but before
examples so people at least see the notes.