@ -147,8 +147,8 @@ Note that we do keep Ansible to a particular aesthetic, so if you are unclear ab
is a good fit or not, having the discussion on the development list is often a lot easier than having
to modify a pull request later.
New module developers should read through `http://docs.ansible.com/ansible/dev_guide/developing_modules.html`_ for helpful pointers
and information about running adhoc tests `http://docs.ansible.com/ansible/dev_guide/developing_modules.html#testing-modules`_.
New module developers should read through `developing modules <http://docs.ansible.com/ansible/dev_guide/developing_modules.html>`_ for helpful pointers
and information about running adhoc tests `testing modules <http://docs.ansible.com/ansible/dev_guide/developing_modules.html#testing-modules>`_.
When submitting patches, be sure to run the unit tests first ``make tests`` and always use, these are the same basic
tests that will automatically run on Shippable when creating the PR. There are more in depth tests in the ``tests/integration``
@ -367,8 +367,7 @@ Use the *--branch* option to import a specific branch. If not specified, the def
Role name
=========
By default the name given to the role will be derived from the GitHub repository name. However, you can use the *--role-name
option to override this and set the name.
By default the name given to the role will be derived from the GitHub repository name. However, you can use the *--role-name* option to override this and set the name.
@ -71,13 +71,13 @@ The top level of the directory would contain files and directories like so::
.._alternative_directory_layout:
Alternative Directory Layout
````````````````
````````````````````````````
Alternatively you can put each inventory file with its ``group_vars``/``host_vars`` in a separate directory. This is particularly useful if your ``group_vars``/``host_vars`` don't have that much in common in different environments. The layout could look something like this::
inventories/
production/
hosts.yml # inventory file for production servers
hosts # inventory file for production servers
group_vars/
group1 # here we assign variables to particular groups
group2 # ""
@ -86,7 +86,7 @@ Alternatively you can put each inventory file with its ``group_vars``/``host_var
hostname2 # ""
staging/
hosts.yml # inventory file for staging environment
hosts # inventory file for staging environment
group_vars/
group1 # here we assign variables to particular groups
Tests in Jinja2 are a way of evaluating template expressions and returning True or False.
Jinja2 ships with many of these. See `builtin tests`_ in the official Jinja2 template documentation.
Tests are very similar to filters and are used mostly the same way, but they can also be used in list
processing filters, like C(map()) and C(select()) to choose items in the list.
Tests are very similar to filters and are used mostly the same way, but they can also be used in list processing filters, like C(map()) and C(select()) to choose items in the list.
Like filters, tests always execute on the Ansible controller, **not** on the target of a task, as they test local data.
@ -676,12 +676,15 @@ period, without the rest of the domain.
``play_hosts`` has been deprecated in 2.2, it was the same as the new ``ansible_play_batch`` variable.
..versionadded:: 2.2
``ansible_play_hosts`` is the full list of all hosts still active in the current play.
..versionadded:: 2.2
``ansible_play_batch`` is available as a list of hostnames that are in scope for the current 'batch' of the play. The batch size is defined by ``serial``, when not set it is equivalent to the whole play (making it the same as ``ansible_play_hosts``).
..versionadded:: 2.3
``ansible_playbook_python`` is the path to the python executable used to invoke the Ansible command line tool.
These vars may be useful for filling out templates with multiple hostnames or for injecting the list into the rules for a load balancer.
{% set support = { 'core': 'This module is maintained by those with core commit privileges', 'committer': 'This module is supported mainly by the community and is curated by core committers', 'community': 'This module is community maintained without core committer oversight'} %}
{% set module_states = { 'preview': 'it is not guaranteed to have a backwards compatible interface', 'stableinterface': 'the maintainers for this module guarantee that the no backward incompatible interface changes will be made'} %}
{% if metadata.supported_by == 'core' %}
{% if metadata %}
{% if metadata.status %}
This is a Core Module
---------------------
Status
~~~~~~
For more information on what this means please read :doc:`modules_core`
{% for cur_state in metadata.status %}
This module is flagged as **@{cur_state}@** which means that @{module_states[cur_state]}@.
{% endfor %}
{% endif %}
{% else %}
{% if metadata.supported_by %}
This module is supported by: @{ metadata.supported_by }@
------------------------
Support
~~~~~~~
For more information on what this means please read :doc:`modules_extra`
@{ support[metadata.supported_by] }@
{% endif %}
{% if metadata.supported_by == 'core' %}
For more information on what this means please read :doc:`modules_core`
{% else %}
For more information on what this means please read :doc:`modules_extra`
{% endif %}
For help in developing on modules, should you be so inclined, please read :doc:`community`, :doc:`developing_test_pr` and :doc:`developing_modules`.
{% endif %}
{% endif %}
{% endif %}
For help in developing on modules, should you be so inclined, please read :doc:`community`, :doc:`dev_guide/developing_test_pr` and :doc:`developing_modules`.
Brian Coca
8 years ago