* Fix 'the the' typos, fix 'pahting' filename typo
* Change 'the the' typos to a single 'the'.
* Change `playbook_pahting.rst` to `playbook_pathing.rst`.
* Delete trailing space in ec2_vol example
Delete the trailing space in `instance: "{{ item.id }} "`, which makes the
example fail when run because it looks for instance "i-xxxx ".
@ -20,7 +20,7 @@ Some tasks that require 'local' resources use action plugins (template and copy
The magic of 'local' paths
The magic of 'local' paths
--------------------------
--------------------------
Lookups and action plugins both use a special 'search magic' to find things, taking the current play into account, it uses from most specific to most general the the playbook dir in which a task is contained (this includes roles and includes).
Lookups and action plugins both use a special 'search magic' to find things, taking the current play into account, it uses from most specific to most general playbook dir in which a task is contained (this includes roles and includes).
Using this magic, relative paths get attempted first with a 'files|templates|vars' appended (if not already present), depending on action being taken, 'files' is the default. (i.e include_vars will use vars/). The paths will be searched from most specific to most general (i.e role before play).
Using this magic, relative paths get attempted first with a 'files|templates|vars' appended (if not already present), depending on action being taken, 'files' is the default. (i.e include_vars will use vars/). The paths will be searched from most specific to most general (i.e role before play).
dependent roles WILL be traversed (i.e task is in role2, role2 is a dependency of role1, role2 will be looked at first, then role1, then play).
dependent roles WILL be traversed (i.e task is in role2, role2 is a dependency of role1, role2 will be looked at first, then role1, then play).
1. Force a task to **run in check mode**, even when the playbook is called **without**``--check``. This is called ``check_mode: yes``.
1. Force a task to **run in check mode**, even when the playbook is called **without**``--check``. This is called ``check_mode: yes``.
2. Force a task to **run in normal mode** and make changes to the system, even when the playbook is called **with**``--check``. This is called ``check_mode: no``.
2. Force a task to **run in normal mode** and make changes to the system, even when the playbook is called **with**``--check``. This is called ``check_mode: no``.
..note:: Prior to version 2.2 only the the equivalent of ``check_mode: no`` existed. The notation for that was ``always_run: yes``.
..note:: Prior to version 2.2 only the equivalent of ``check_mode: no`` existed. The notation for that was ``always_run: yes``.
Instead of ``yes``/``no`` you can use a Jinja2 expression, just like the ``when`` clause.
Instead of ``yes``/``no`` you can use a Jinja2 expression, just like the ``when`` clause.
@ -51,7 +51,7 @@ Example::
Running single tasks with ``check_mode: yes`` can be useful to write tests for
Running single tasks with ``check_mode: yes`` can be useful to write tests for
ansible modules, either to test the module itself or to the the conditions under
ansible modules, either to test the module itself or to the conditions under
which a module would make changes.
which a module would make changes.
With ``register`` (see :doc:`playbooks_conditionals`) you can check the
With ``register`` (see :doc:`playbooks_conditionals`) you can check the
Filters in Ansible are from Jinja2, and are used for transforming data inside a template expression. Jinja2 ships with many filters. See `builtin filters`_ in the official Jinja2 template documentation.
Filters in Ansible are from Jinja2, and are used for transforming data inside a template expression. Jinja2 ships with many filters. See `builtin filters`_ in the official Jinja2 template documentation.
Take into account that templating happens on the the Ansible controller, **not** on the task's target host, so filters also execute on the controller as they manipulate local data.
Take into account that templating happens on the Ansible controller, **not** on the task's target host, so filters also execute on the controller as they manipulate local data.
In addition the ones provided by Jinja2, Ansible ships with it's own and allows users to add their own custom filters.
In addition the ones provided by Jinja2, Ansible ships with it's own and allows users to add their own custom filters.