ansible.builtin.assert module – Asserts given expressions are true
Note
This module is part of ansible-core
and included in all Ansible
installations. In most cases, you can use the short
module name
assert
even without specifying the collections keyword.
However, we recommend you use the Fully Qualified Collection Name (FQCN) ansible.builtin.assert
for easy linking to the
module documentation and to avoid conflicting with other collections that may have
the same module name.
Synopsis
This module asserts that given expressions are true with an optional custom message.
This module is also supported for Windows targets.
Note
This module has a corresponding action plugin.
Parameters
Parameter |
Comments |
---|---|
The customized message used for a failing assertion. This argument was called ‘msg’ before Ansible 2.7, now it is renamed to ‘fail_msg’ with alias ‘msg’. |
|
Set this to Choices:
|
|
The customized message used for a successful assertion. |
|
A list of string expressions of the same form that can be passed to the ‘when’ statement. |
Attributes
Attribute |
Support |
Description |
---|---|---|
Support: full |
Indicates this has a corresponding action plugin so some parts of the options can be executed on the controller |
|
Support: none |
Supports being used with the |
|
Support: none |
Is usable alongside become keywords |
|
Support: none |
Forces a ‘global’ task that does not execute per host, this bypasses per host templating and serial, throttle and other loop considerations Conditionals will work as if This action will not work normally outside of lockstep strategies |
|
Support: full |
Can run in check_mode and return changed status prediction without modifying target, if not supported the action will be skipped. |
|
Support: none |
Uses the target’s configured connection information to execute code on it |
|
Support: none Aside from |
Can be used in conjunction with delegate_to and related keywords |
|
Support: none |
Will return details on what has changed (or possibly needs changing in check_mode), when in diff mode |
|
Platforms: all |
Target OS/families that can be operated against |
See Also
See also
- ansible.builtin.debug
Print statements during execution.
- ansible.builtin.fail
Fail with custom message.
- ansible.builtin.meta
Execute Ansible ‘actions’.
Examples
- name: A single condition can be supplied as string instead of list
ansible.builtin.assert:
that: "ansible_os_family != 'RedHat'"
- name: Use yaml multiline strings to ease escaping
ansible.builtin.assert:
that:
- "'foo' in some_command_result.stdout"
- number_of_the_counting == 3
- >
"reject" not in some_command_result.stderr
- name: After version 2.7 both 'msg' and 'fail_msg' can customize failing assertion message
ansible.builtin.assert:
that:
- my_param <= 100
- my_param >= 0
fail_msg: "'my_param' must be between 0 and 100"
success_msg: "'my_param' is between 0 and 100"
- name: Please use 'msg' when ansible version is smaller than 2.7
ansible.builtin.assert:
that:
- my_param <= 100
- my_param >= 0
msg: "'my_param' must be between 0 and 100"
- name: Use quiet to avoid verbose output
ansible.builtin.assert:
that:
- my_param <= 100
- my_param >= 0
quiet: true