ansible.builtin.import_playbook module – Import a playbook
Note
This module is part of ansible-core
and included in all Ansible
installations. In most cases, you can use the short
module name
import_playbook
even without specifying the collections keyword.
However, we recommend you use the Fully Qualified Collection Name (FQCN) ansible.builtin.import_playbook
for easy linking to the
module documentation and to avoid conflicting with other collections that may have
the same module name.
Synopsis
Includes a file with a list of plays to be executed.
Files with a list of plays can only be included at the top level.
You cannot use this action inside a play.
Parameters
Parameter |
Comments |
---|---|
The name of the imported playbook is specified directly without any other option. |
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: partial While the import can be host specific and runs per host it is not dealing with all available host variables, use an include instead for those cases |
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: partial The task itself is not looped, but the loop is applied to each imported task |
These tasks ignore the |
|
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: 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 imports |
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 While the action itself will ignore the conditional, it will be inherited by the imported tasks themselves |
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 not interpreted for this action, they are applied to the imported tasks |
Allows for the ‘tags’ keyword to control the selection of this action for execution |
|
Support: full |
Denotes if this action obeys until/retry/poll keywords |
Notes
Note
This is a core feature of Ansible, rather than a module, and cannot be overridden like a module.
See Also
See also
- ansible.builtin.import_role
Import a role into a play.
- ansible.builtin.import_tasks
Import a task list.
- ansible.builtin.include_role
Load and execute a role.
- ansible.builtin.include_tasks
Dynamically include a task list.
- Re-using Ansible artifacts
More information related to including and importing playbooks, roles and tasks.
Examples
- hosts: localhost
tasks:
- ansible.builtin.debug:
msg: play1
- name: Include a play after another play
ansible.builtin.import_playbook: otherplays.yaml
- name: Set variables on an imported playbook
ansible.builtin.import_playbook: otherplays.yml
vars:
service: httpd
- name: Include a playbook from a collection
ansible.builtin.import_playbook: my_namespace.my_collection.my_playbook
- name: This DOES NOT WORK
hosts: all
tasks:
- ansible.builtin.debug:
msg: task1
- name: This fails because I'm inside a play already
ansible.builtin.import_playbook: stuff.yaml