ansible-collections/community.general
1
0
Fork 0
mirror of https://github.com/ansible-collections/community.general.git synced 2025-04-30 14:21:26 -07:00
Code Issues Projects Releases Packages Wiki Activity Actions 11

Deprecate tests used as filters (#32361)

Browse source 
* Warn on tests used as filters

* Update docs, add aliases for tests that fit more gramatically with test syntax

* Fix rst formatting

* Add successful filter, alias of success

* Remove renamed_deprecation, it was overkill

* Make directory alias for is_dir

* Update tests to use proper jinja test syntax

* Update additional documentation, living outside of YAML files, to reflect proper jinja test syntax

* Add conversion script, porting guide updates, and changelog updates

* Update newly added uses of tests as filters

* No underscore variable

* Convert recent tests as filter changes to win_stat

* Fix some changes related to rebasing a few integration tests

* Make tests_as_filters_warning explicitly accept the name of the test, instead of inferring the name

* Add test for tests_as_filters_warning

* Update tests as filters in newly added/modified tests

* Address recent changes to several integration tests

* Address recent changes in cs_vpc
This commit is contained in:
Matt Martz 2017-11-27 16:58:08 -06:00 • committed by ansibot
parent fd4a6cf7ad
commit 4fe08441be
349 changed files with 4086 additions and 3844 deletions
Download patch file Download diff file Expand all files Collapse all files

2
docs/docsite/rst/become.rst
View file

@ -296,7 +296,7 @@ If running on a version of Ansible that is older than 2.5 or the normal
- name: reboot after disabling UAC
win_reboot:
when: uac_result|changed
when: uac_result is changed
.. Note:: Granting the ``SeTcbPrivilege`` or turning UAC off can cause Windows
security vulnerabilities and care should be given if these steps are taken.

6
docs/docsite/rst/dev_guide/developing_modules_general_windows.rst
View file

@ -252,7 +252,7 @@ idempotent and does not report changes. For example:
- name: assert remove a file (check mode)
assert:
that:
- remove_file_check|changed
- remove_file_check is changed
- remove_file_actual_check.stdout == 'true\r\n'
- name: remove a file
@ -268,7 +268,7 @@ idempotent and does not report changes. For example:
- name: assert remove a file
assert:
that:
- remove_file|changed
- remove_file is changed
- remove_file_actual.stdout == 'false\r\n'
- name: remove a file (idempotent)
@ -280,7 +280,7 @@ idempotent and does not report changes. For example:
- name: assert remove a file (idempotent)
assert:
that:
- not remove_file_again|changed
- not remove_file_again is changed
Windows communication and development support

8
docs/docsite/rst/playbooks_conditionals.rst
View file

@ -57,14 +57,14 @@ decide to do something conditionally based on success or failure::
ignore_errors: True
- command: /bin/something
when: result|failed
when: result is failed
# In older versions of ansible use |success, now both are valid but succeeded uses the correct tense.
# In older versions of ansible use ``success``, now both are valid but succeeded uses the correct tense.
- command: /bin/something_else
when: result|succeeded
when: result is succeeded
- command: /bin/still/something_else
when: result|skipped
when: result is skipped
.. note:: both `success` and `succeeded` work (`fail`/`failed`, etc).

80
docs/docsite/rst/playbooks_tests.rst
View file

@ -4,14 +4,32 @@ Tests
.. contents:: Topics
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 <http://jinja.pocoo.org/docs/dev/templates/#tests>`_ in Jinja are a way of evaluating template expressions and returning True or False.
Jinja ships with many of these. See `builtin tests`_ in the official Jinja template documentation.
The main difference between tests and filters are that Jinja tests are used for comparisons, whereas filters are used for data manipulation, and have different applications in jinja. Tests can also be used in list processing filters, like C(map()) and C(select()) to choose items in the list.
Like all templating, tests always execute on the Ansible controller, **not** on the target of a task, as they test local data.
In addition to those Jinja2 tests, Ansible supplies a few more and users can easily create their own.
.. _test_syntax:
Test syntax
```````````
`Test syntax <http://jinja.pocoo.org/docs/dev/templates/#tests>`_ varies from `filter syntax <http://jinja.pocoo.org/docs/dev/templates/#filters>`_ (``variable | filter``). Historically Ansible has registered tests as both jinja tests and jinja filters, allowing for them to be referenced using filter syntax.
As of Ansible 2.5, using a jinja test as a filter will generate a warning.
The syntax for using a jinja test is as follows::
variable is test_name
Such as::
result is failed
.. _testing_strings:
Testing strings
@ -24,13 +42,13 @@ To match strings against a substring or a regex, use the "match" or "search" fil
tasks:
- debug: "msg='matched pattern 1'"
when: url | match("http://example.com/users/.*/resources/.*")
when: url is match("http://example.com/users/.*/resources/.*")
- debug: "msg='matched pattern 2'"
when: url | search("/users/.*/resources/.*")
when: url is search("/users/.*/resources/.*")
- debug: "msg='matched pattern 3'"
when: url | search("/users/")
when: url is search("/users/")
'match' requires a complete match in the string, while 'search' only requires matching a subset of the string.
@ -42,23 +60,25 @@ Version Comparison
.. versionadded:: 1.6
.. note:: In 2.5 ``version_compare`` was renamed to ``version``
To compare a version number, such as checking if the ``ansible_distribution_version``
version is greater than or equal to '12.04', you can use the ``version_compare`` filter.
version is greater than or equal to '12.04', you can use the ``version`` test.
The ``version_compare`` filter can also be used to evaluate the ``ansible_distribution_version``::
The ``version`` test can also be used to evaluate the ``ansible_distribution_version``::
{{ ansible_distribution_version | version_compare('12.04', '>=') }}
{{ ansible_distribution_version is version('12.04', '>=') }}
If ``ansible_distribution_version`` is greater than or equal to 12, this filter returns True, otherwise False.
If ``ansible_distribution_version`` is greater than or equal to 12, this test returns True, otherwise False.
The ``version_compare`` filter accepts the following operators::
The ``version`` test accepts the following operators::
<, lt, <=, le, >, gt, >=, ge, ==, =, eq, !=, <>, ne
This test also accepts a 3rd parameter, ``strict`` which defines if strict version parsing should
be used. The default is ``False``, but this setting as ``True`` uses more strict version parsing::
{{ sample_version_var | version_compare('1.0', operator='lt', strict=True) }}
{{ sample_version_var is version('1.0', operator='lt', strict=True) }}
.. _math_tests:
@ -68,17 +88,19 @@ Group theory tests
.. versionadded:: 2.1
To see if a list includes or is included by another list, you can use 'issubset' and 'issuperset'::
.. note:: In 2.5 ``issubset`` and ``issuperset`` were renamed to ``subset`` and ``superset``
To see if a list includes or is included by another list, you can use 'subset' and 'superset'::
vars:
a: [1,2,3,4,5]
b: [2,3]
tasks:
- debug: msg="A includes B"
when: a|issuperset(b)
when: a is superset(b)
- debug: msg="B is included in A"
when: b|issubset(a)
when: b is subset(a)
.. _path_tests:
@ -101,33 +123,35 @@ You can use `any` and `all` to check if any or all elements in a list are true o
when: mylist is all
- debug: msg="at least one is true"
when: myotherlist|any
when: myotherlist is any
Testing paths
`````````````
.. note:: In 2.5 the follwing tests were renamed to remove the ``is_`` prefix
The following tests can provide information about a path on the controller::
- debug: msg="path is a directory"
when: mypath|is_dir
when: mypath is directory
- debug: msg="path is a file"
when: mypath|is_file
when: mypath is file
- debug: msg="path is a symlink"
when: mypath|is_link
when: mypath is link
- debug: msg="path already exists"
when: mypath|exists
when: mypath is exists
- debug: msg="path is {{ (mypath|is_abs)|ternary('absolute','relative')}}"
- debug: msg="path is {{ (mypath is abs)|ternary('absolute','relative')}}"
- debug: msg="path is the same file as path2"
when: mypath|samefile(path2)
when: mypath is same_file(path2)
- debug: msg="path is a mount"
when: mypath|is_mount
when: mypath is mount
.. _test_task_results:
@ -144,20 +168,20 @@ The following tasks are illustrative of the tests meant to check the status of t
ignore_errors: True
- debug: msg="it failed"
when: result|failed
when: result is failed
# in most cases you'll want a handler, but if you want to do something right now, this is nice
- debug: msg="it changed"
when: result|changed
when: result is changed
- debug: msg="it succeeded in Ansible >= 2.1"
when: result|succeeded
when: result is succeeded
- debug: msg="it succeeded"
when: result|success
when: result is success
- debug: msg="it was skipped"
when: result|skipped
when: result is skipped
.. note:: From 2.1, you can also use success, failure, change, and skip so that the grammar matches, for those who need to be strict about it.

39
docs/docsite/rst/porting_guide_2.5.rst
View file

@ -22,7 +22,42 @@ No notable changes.
Deprecated
==========
No notable changes.
Jinja tests used as filters
---------------------------
Using Ansible provided jinja tests as filters will be removed in Ansible 2.9.
Prior to Ansible 2.5, jinja tests included within Ansible were most often used as filters. The large difference in use is that filters are referenced as ``variable | filter_name`` where as jinja tests are refereced as ``variable is test_name``.
Jinja tests are used for comparisons, whereas filters are used for data manipulation, and have different applications in jinja. This change is to help differentiate the concepts for a better understanding of jinja, and where each can be appropriately used.
As of Ansible 2.5 using an Ansible provided jinja test with filter syntax, will display a deprecation error.
**OLD** In Ansible 2.4 (and earlier) the use of an Ansible included jinja test would likely look like this:
.. code-block:: yaml
when:
- result | failed
- not result | success
**NEW** In Ansible 2.5 it should be changed to look like this:
.. code-block:: yaml
when:
- result is failed
- results is not successful
In addition to the deprecation warnings, many new tests have been introduced that are aliases of the old tests, that make more sense grammatically with the jinja test syntax such as the new ``successful`` test which aliases ``success``
.. code-block:: yaml
when: result is successful
See :ref:`The Ansible Tests Documentation <playbooks_tests>` for more information.
Additionally, a script was created to assist in the conversion for tests using filter syntax to proper jinja test syntax. This script has been used to convert all of the Ansible integration tests to the correct format. There are a few limitations documented, and all changes made by this script should be evaluated for correctness before executing the modified playbooks. The script can be found at `https://github.com/ansible/ansible/blob/devel/hacking/fix_test_syntax.py <https://github.com/ansible/ansible/blob/devel/hacking/fix_test_syntax.py>`_.
Modules
=======
@ -41,7 +76,7 @@ The following modules no longer exist:
Deprecation notices
-------------------
The following modules will be removed in Ansible 2.8. Please update update your playbooks accordingly.
The following modules will be removed in Ansible 2.9. Please update update your playbooks accordingly.
* :ref:`fixme <fixme>`