ansible-collections/community.general
1
0
Fork 0
mirror of https://github.com/ansible-collections/community.general.git synced 2025-04-25 03:41:25 -07:00
Code Issues Projects Releases Packages Wiki Activity Actions 9

Docs how to test (2nd) (#24094)

Browse source 
* Big testing doc refactor
* Combine all the testing documentation in to one place to make it easier to find
* Convert everything to RST
* Create testing_network guide
* Create testing landing page
* For each section detail "how to run" and "how to extend testing"
* More examples
* Lots more detail
This commit is contained in:
John R Barker 2017-04-28 09:08:26 +01:00 • committed by GitHub
parent bc22223d63
commit ecbf8e933a
22 changed files with 866 additions and 558 deletions
Download patch file Download diff file Expand all files Collapse all files

8
docs/docsite/rst/dev_guide/developing_modules_in_groups.rst
View file

@ -25,8 +25,9 @@ Although it's tempting to get straight into coding, there are a few things to be
* Have a look at the existing modules and how they've been named in the :doc:`../list_of_all_modules`, especially in the same functional area (such as cloud, networking, databases).
* Shared code can be placed into ``lib/ansible/module_utils/``
* Shared documentation (for example describing common arguments) can be placed in ``lib/ansible/utils/module_docs_fragments/``.
* With great power comes great responsiblity: Ansible module maintainers have a duty to help keep modules up to date. As with all successful community projects, module maintainers should keep a watchful eye for reported issues and contributions.
* Although not required, unit and/or integration tests are strongly recommended. Unit tests are especially valuable when external resources (such as cloud or network devices) are required. For more information see ``test/`` and the `Testing Working Group <https://github.com/ansible/community/blob/master/MEETINGS.md>`_.
* With great power comes great responsibility: Ansible module maintainers have a duty to help keep modules up to date. As with all successful community projects, module maintainers should keep a watchful eye for reported issues and contributions.
* Although not required, unit and/or integration tests are strongly recommended. Unit tests are especially valuable when external resources (such as cloud or network devices) are required. For more information see :doc:`testing` and the `Testing Working Group <https://github.com/ansible/community/blob/master/MEETINGS.md>`_.
* Starting with Ansible 2.4 all :doc:`../list_of_network_modules` MUST have unit tests.
Naming Convention
`````````````````
@ -96,7 +97,7 @@ After publishing your PR to https://github.com/ansible/ansible, a Shippable CI t
If you need further advice, consider join the ``#ansible-devel`` IRC channel (see how in the "Where to get support").
We have a "ansibot" helper that comments on GitHub Issues and PRs which should highlight important information.
We have a ``ansibullbot`` helper that comments on GitHub Issues and PRs which should highlight important information.
Subsequent PRs
@ -146,4 +147,3 @@ Please note that in the Ansible Git Repo the main branch is called ``devel`` rat
After your first PR has been merged ensure you "sync your fork" with ``ansible/ansible`` to ensure you've pulled in the directory structure and and shared code or documentation previously created.
As stated in the GitHub documentation, always use feature branches for your PRs, never commit directly into `devel`.