- Syntax
- YAML FILE
- Templating
- Jinja2
- Content
- A list of task definitions and task includes
Anywhere there can be a task definition, you can also use a task include:
- include: <path to tasks file> [options]
The path is relative to the :ref:`playbook-directory`, or the file is also searched for in the tasks directory of a role.
[options]
is an optional list of additional variable
settings, e.g.:
- include: tasks/footasks.yml vara=1 varb=2 varc=3
You can use an expanded syntax with a vars setting to set more complicated values:
- include: wordpress.yml vars: wp_user: timmy some_list_variable: - alpha - beta - gamma
Or use this more compact but apparently equivalent syntax:
- { include: wordpress.yml, wp_user: timmy, ssh_keys: [ 'keys/one.txt', 'keys/two.txt' ] }
You can do the equivalent of a conditional include by adding when
:
- include: othertask.yml when: "'reticulating splines' in output"
This is implemented by including the task file but applying the when statement to every task in it, so you'll see all the individual tasks being skipped.
A dictionary:
name: string # optional but highly recommended module: args # required; the "action" environment: dictionary remote_user: username sudo: yes|no sudo_user: username otheroption: othervalue # depending on module
Required keys:
- name
- text
- modulename
- options
Optional keys that can be used on any task:
- environment
- dictionary (in YAML, or variable containing dictionary)
- remote_user
- user to login as remotely
- sudo
- yes|no
- sudo_user
- user to sudo to remotely
Additional keys might be required and optional depending on the module being used.
Same syntax as a :ref:`task`, it just gets triggered under different circumstances.