[backport][2.10] Docsbackportapaloosa (#70302)

* Fix broken link in AWS Guide (#70153)

Point to collection rather than ansible/ansible for example.

(cherry picked from commit 0ef75f65d9)

* remove gendered example (#70117)

Changed example to not assume things about names and genders

(cherry picked from commit 5885ed4455)

* docs: Add note about ansible-doc (#70162)

ansible-doc can only parse Python modules, added a note about
this is developer guide; Fixes: #69109

(cherry picked from commit da868d9d60)

* Update config.yml (#70154)

typos & branding
* Update .github/ISSUE_TEMPLATE/config.yml

Co-authored-by: Rick Elrod <rick@elrod.me>
(cherry picked from commit 4b358c6641)

* async_status: Update documentation (#70196)

Fixes: #38164

Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com>
(cherry picked from commit 40a42de081)

* updates to ansible-maintained collections guidelines (#70178)

(cherry picked from commit 647c6cd289)

Co-authored-by: Jill R <4121322+jillr@users.noreply.github.com>
Co-authored-by: Westley Argentum Hennigh-Palermo <WestleyArgentum@gmail.com>
Co-authored-by: Abhijeet Kasurde <akasurde@redhat.com>
Co-authored-by: John R Barker <john@johnrbarker.com>
This commit is contained in:
Sandra McCann 2020-06-25 11:17:49 -04:00 committed by GitHub
parent 2a4f4dd526
commit 222d35ebbd
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
8 changed files with 74 additions and 43 deletions

View file

@ -20,7 +20,7 @@ contact_links:
about: Please ask and answer usage questions here
- name: ⚡ Working groups
url: https://github.com/ansible/community/wiki
about: Interedted in improving a specific area? Become a part of a working group!
about: Interested in improving a specific area? Become a part of a working group!
- name: 💼 For Enterprise
url: https://www.ansible.com/products/engine?utm_medium=github&utm_source=issue_template_chooser
about: Red Hat offers supported builds of Ansible Engine
about: Red Hat offers support for the Ansible Automation Platform

View file

@ -120,7 +120,7 @@ The following table shows:
</tr>
<tr>
<td><a href="https://galaxy.ansible.com/cisco/asa">cisco.asa</a></td>
<td>community.asa</td>
<td><a href="https://github.com/ansible-collections/community.asa">community.asa</a></td>
<td><a href="https://github.com/ansible/community/wiki/Security-Automation">Security</a></td>
<td>✓</td>
<td>✓</td>
@ -164,7 +164,7 @@ The following table shows:
</tr>
<tr>
<td><a href="https://galaxy.ansible.com/ibm/qradar">ibm.qradar</a></td>
<td>community.qradar</td>
<td><a href="https://github.com/ansible-collections/community.qradar">community.qradar</a></td>
<td><a href="https://github.com/ansible/community/wiki/Security-Automation">Security</a></td>
<td>✓</td>
<td></td>
@ -197,7 +197,7 @@ The following table shows:
</tr>
<tr>
<td><a href="https://github.com/ansible-collections/splunk.es">splunk.es</a></td>
<td>community.es</td>
<td><a href="https://github.com/ansible-collections/community.es">community.es</a></td>
<td><a href="https://github.com/ansible/community/wiki/Security-Automation">Security</a></td>
<td>✓</td>
<td></td>
@ -250,7 +250,7 @@ The following scenarios use the ``arista.eos`` to help explain when to contribut
* Propose a new module in the ``community.network`` collection (requires network community approval).
* Place your new module in a collection in your own namespace (no approvals required).
Most new content should go into either a related community collection or your own collection first so that is well established in the community before you can propose adding it to the ``arista`` namespace, where inclusion and maintenance criteria are much higher.

View file

@ -45,6 +45,10 @@ To confirm that ``my_custom_module`` is available:
* type ``ansible-doc -t module my_custom_module``. You should see the documentation for that module.
.. note::
Currently, ``ansible-doc`` command can only parse Python modules for the module documentation. If you have module written in a different programming language other than Python, please write a documentation in Python file adjacent to module file.
To use a local module only in certain playbooks:
* store it in a sub-directory called ``library`` in the directory that contains the playbook(s)

View file

@ -638,7 +638,7 @@ available during the test run. Second putting the test in a test group causing i
continuous integration build.
Tests for new modules should be added to the same group as existing AWS tests. In general just copy
an existing aliases file such as the `aws_s3 tests aliases file <https://github.com/ansible/ansible/blob/devel/test/integration/targets/aws_s3/aliases>`_.
an existing aliases file such as the `aws_s3 tests aliases file <https://github.com/ansible-collections/amazon.aws/blob/master/tests/integration/targets/aws_s3/aliases>`_.
AWS Credentials for Integration Tests
-------------------------------------

View file

@ -511,9 +511,9 @@ For platforms that support ``connection: local`` *and* ``connection: network_cli
* Name the :file:`targets/` directories after the module name.
* The :file:`main.yaml` file should just reference the transport.
The following example walks through the integration tests for the ``vyos.vyos.vyos_banner`` module in the `vyos.vyos <https://github.com/ansible-collections/vyos.vyos/tree/master/tests/integration>`_ collection:
The following example walks through the integration tests for the ``vyos.vyos.vyos_l3_interfaces`` module in the `vyos.vyos <https://github.com/ansible-collections/vyos.vyos/tree/master/tests/integration>`_ collection:
``test/integration/targets/vyos_banner/tasks/main.yaml``
``test/integration/targets/vyos_l3_interfaces/tasks/main.yaml``
.. code-block:: yaml
@ -522,7 +522,7 @@ The following example walks through the integration tests for the ``vyos.vyos.vy
tags:
- cli
``test/integration/targets/vyos_banner/tasks/cli.yaml``
``test/integration/targets/vyos_l3_interfaces/tasks/cli.yaml``
.. code-block:: yaml
@ -549,46 +549,71 @@ The following example walks through the integration tests for the ``vyos.vyos.vy
loop_control:
loop_var: test_case_to_run
``test/integration/targets/vyos_banner/tests/cli/basic-no-login.yaml``
``test/integration/targets/vyos_l3_interfaces/tests/cli/overridden.yaml``
.. code-block:: yaml
---
- debug:
msg: "cli/basic-no-login.yaml on connection={{ ansible_connection }}"
---
- debug:
msg: START vyos_l3_interfaces merged integration tests on connection={{ ansible_connection
}}
- name: Setup
vyos_banner:
banner: pre-login
text: |
Junk pre-login banner
over multiple lines
state: present
- include_tasks: _remove_config.yaml
- name: remove pre-login
vyos_banner:
banner: pre-login
state: absent
- block:
- include_tasks: _populate.yaml
- name: Overrides all device configuration with provided configuration
register: result
vyos.vyos.vyos_l3_interfaces: &id001
config:
- debug:
msg: "{{ result }}"
- name: eth0
ipv4:
- assert:
- address: dhcp
- name: eth1
ipv4:
- address: 192.0.2.15/24
state: overridden
- name: Assert that before dicts were correctly generated
assert:
that:
- "result.changed == true"
- "'delete system login banner pre-login' in result.commands"
- "{{ populate | symmetric_difference(result['before']) |length == 0 }}"
- name: remove pre-login (idempotent)
vyos_banner:
banner: pre-login
state: absent
- name: Assert that correct commands were generated
assert:
that:
- "{{ overridden['commands'] | symmetric_difference(result['commands'])\
\ |length == 0 }}"
- name: Assert that after dicts were correctly generated
assert:
that:
- "{{ overridden['after'] | symmetric_difference(result['after']) |length\
\ == 0 }}"
- name: Overrides all device configuration with provided configurations (IDEMPOTENT)
register: result
vyos.vyos.vyos_l3_interfaces: *id001
- assert:
- name: Assert that the previous task was idempotent
assert:
that:
- "result.changed == false"
- "result.commands | length == 0"
- result['changed'] == false
- name: Assert that before dicts were correctly generated
assert:
that:
- "{{ overridden['after'] | symmetric_difference(result['before']) |length\
\ == 0 }}"
always:
- include_tasks: _remove_config.yaml
Detecting test resources at runtime
@ -659,14 +684,14 @@ To run integration tests for a specific module:
.. code-block:: bash
ansible-test network-integration --inventory /path/to-collection-module/test/integration/inventory.networking vyos_vlan
ansible-test network-integration --inventory /path/to-collection-module/test/integration/inventory.networking vyos_l3_interfaces
To run a single test case on a specific module:
.. code-block:: bash
# Only run vyos_vlan/tests/cli/basic.yaml
ansible-test network-integration --inventory /path/to-collection-module/test/integration/inventory.networking vyos_vlan --testcase basic
# Only run vyos_l3_interfaces/tests/cli/gathered.yaml
ansible-test network-integration --inventory /path/to-collection-module/test/integration/inventory.networking vyos_l3_interfaces --testcase gathered
To run integration tests for a specific transport:

View file

@ -102,7 +102,8 @@ If you need a synchronization point with an async task, you can register it to o
jid: "{{ yum_sleeper.ansible_job_id }}"
register: job_result
until: job_result.finished
retries: 30
retries: 100
delay: 10
.. note::
If the value of ``async:`` is not high enough, this will cause the

View file

@ -76,7 +76,7 @@ Defining different values for true/false/null
You can create a test, then define one value to use when the test returns true and another when the test returns false (new in version 1.9)::
{{ (name == "John") | ternary('Mr','Ms') }}
{{ (status == "needs_restart") | ternary('restart', 'continue') }}
In addition, you can define a one value to use on true, one value on false and a third value on null (new in version 2.8)::

View file

@ -54,7 +54,8 @@ EXAMPLES = r'''
jid: '{{ yum_sleeper.ansible_job_id }}'
register: job_result
until: job_result.finished
retries: 30
retries: 100
delay: 10
'''
RETURN = r'''