ansible.builtin.import_role – Import a role into a play
This module is part of
ansible-core and included in all Ansible
installations. In most cases, you can use the short
import_role even without specifying the
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
Much like the
roles:keyword, this task loads a role, but it allows you to control when the role tasks run in between other tasks of the play.
Most keywords, loops and conditionals will only be applied to the imported tasks, not to this statement itself. If you want the opposite behavior, use ansible.builtin.include_role instead.
Does not work in handlers.
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
Supports being used with the
Is usable alongside become keywords
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
run_onceis being used, variables used will be from the first available host
This action will not work normally outside of lockstep strategies
The task itself is not looped, but the loop is applied to each imported task
These tasks ignore the
Can run in check_mode and return changed status prediction withought modifying target
Uses the target’s configured connection information to execute code on it
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.
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
Will return details on what has changed (or possibly needs changing in check_mode), when in diff mode
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
Target OS/families that can be operated against
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
Denotes if this action objeys until/retry/poll keywords
Handlers are made available to the whole play.
Since Ansible 2.7 variables defined in
defaultsfor the role are exposed to the play at playbook parsing time. Due to this, these variables will be accessible to roles and tasks executed before the location of the ansible.builtin.import_role task.
Unlike ansible.builtin.include_role variable exposure is not configurable, and will always be exposed.
The official documentation on the ansible.builtin.import_playbook module.
The official documentation on the ansible.builtin.import_tasks module.
The official documentation on the ansible.builtin.include_role module.
The official documentation on the ansible.builtin.include_tasks module.
- Including and importing
More information related to including and importing playbooks, roles and tasks.
- hosts: all tasks: - import_role: name: myrole - name: Run tasks/other.yaml instead of 'main' import_role: name: myrole tasks_from: other - name: Pass variables to role import_role: name: myrole vars: rolevar1: value from task - name: Apply condition to each task in role import_role: name: myrole when: not idontwanttorun