You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/docsite/rst/playbook_guide/playbooks_handlers.rst
+18-3Lines changed: 18 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -144,9 +144,24 @@ Notifying the ``restart web services`` topic results in executing all handlers l
144
144
145
145
This use makes it much easier to trigger multiple handlers. It also decouples handlers from their names, making it easier to share handlers among playbooks and roles (especially when using third-party roles from a shared source such as Ansible Galaxy).
146
146
147
-
Each handler should have a globally unique name. If multiple handlers are defined with the same name, only the last one loaded into the play can be notified and executed, effectively shadowing all of the previous handlers with the same name.
147
+
Each handler should have a globally unique name. If multiple handlers are defined with the same name, only the last one loaded into the play (see `handlers_insertion_order`_) can be notified and executed, effectively shadowing all of the previous handlers with the same name.
148
148
149
-
There is only one global scope for handlers (handler names and listen topics) regardless of where the handlers are defined. This also includes handlers defined in roles.
149
+
.. _handlers_insertion_order:
150
+
151
+
Handler insertion order into the play
152
+
--------------------------------------
153
+
154
+
There is only one global, play-level scope for handlers regardless of where the handlers are defined, either in the ``handlers:`` section or in roles. The order in which handlers are added into the play is as follows:
155
+
156
+
#. Handlers from roles in the ``roles:`` section.
157
+
158
+
#. Handlers from the ``handlers:`` section.
159
+
160
+
#. Handlers from roles statically imported via ``import_role`` tasks.
161
+
162
+
#. Handlers from roles dynamically included via ``include_role`` tasks (available at runtime only after the ``include_role`` task executed).
163
+
164
+
In case handlers having the same name the last one loaded into the play, as per the above order, can be notified and executed.
150
165
151
166
Controlling when handlers run
152
167
-----------------------------
@@ -226,7 +241,7 @@ Handlers in roles
226
241
227
242
Handlers from roles are not just contained in their roles but rather inserted into the global scope with all other handlers from a play. As such they can be used outside of the role they are defined in. It also means that their name can conflict with handlers from outside the role. To ensure that a handler from a role is notified as opposed to one from outside the role with the same name, notify the handler by using its name in the following form: ``role_name : handler_name``.
228
243
229
-
Handlers notified within the ``roles`` section are automatically flushed at the end of the ``tasks`` section but before any ``tasks`` handlers.
244
+
Handlers notified within the ``roles`` section are automatically flushed at the end of the ``tasks`` section.
0 commit comments