ansible.builtin.include_tasks module – Dynamically include a task list
Note
This module is part of ansible-core
and included in all Ansible
installations. In most cases, you can use the short
module name
include_tasks
even without specifying the collections:
keyword.
However, we recommend you use the FQCN for easy linking to the
module documentation and to avoid conflicting with other collections that may have
the same module name.
New in version 2.4: of ansible.builtin
Parameters
Parameter |
Comments |
---|---|
Accepts a hash of task keywords (e.g. |
|
The name of the imported file is specified directly without any other option. Unlike ansible.builtin.import_tasks, most keywords, including loop, with_items, and conditionals, apply to this statement. The do until loop is not supported on ansible.builtin.include_tasks. |
|
|
Attributes
Attribute |
Support |
Description |
---|---|---|
Support: none While this action executes locally on the controller it is not governed by an action plugin |
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: none |
These tasks ignore the |
|
Support: none |
Can run in check_mode and return changed status prediction withought modifying target |
|
Support: none |
Uses the target’s configured connection information to execute code on it |
|
Support: full |
This is a ‘core engine’ feature and is not implemented like most task actions, so it is not overridable in any way via the plugin system. |
|
Support: none Since there are no connection nor facts, there is no sense in delegating includes |
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 |
|
Support: none |
The action is not subject to conditional execution so it will ignore the |
|
Platforms: all |
Target OS/families that can be operated against |
|
Support: full Tags are interpreted by this action but are not automatically inherited by the include tasks, see |
Allows for the ‘tags’ keyword to control the selection of this action for execution |
|
Support: full |
Denotes if this action objeys until/retry/poll keywords |
See Also
See also
- ansible.builtin.import_playbook
The official documentation on the ansible.builtin.import_playbook module.
- ansible.builtin.import_role
The official documentation on the ansible.builtin.import_role module.
- ansible.builtin.import_tasks
The official documentation on the ansible.builtin.import_tasks module.
- ansible.builtin.include_role
The official documentation on the ansible.builtin.include_role module.
- Including and importing
More information related to including and importing playbooks, roles and tasks.
Examples
- hosts: all
tasks:
- debug:
msg: task1
- name: Include task list in play
include_tasks: stuff.yaml
- debug:
msg: task10
- hosts: all
tasks:
- debug:
msg: task1
- name: Include task list in play only if the condition is true
include_tasks: "{{ hostvar }}.yaml"
when: hostvar is defined
- name: Apply tags to tasks within included file
include_tasks:
file: install.yml
apply:
tags:
- install
tags:
- always
- name: Apply tags to tasks within included file when using free-form
include_tasks: install.yml
args:
apply:
tags:
- install
tags:
- always
Authors
Ansible Core Team (@ansible)