# Trigger task sequences in handlers

**URL:** <https://forum.ansible.com/t/trigger-task-sequences-in-handlers/12638>\
**Category:** Ansible Project\
**Tags:** ansible-project\
**Created:** [April 5, 2013, 9:26pm UTC](https://forum.ansible.com/t/trigger-task-sequences-in-handlers/12638 "2013-04-05T21:26:04Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Serge\_van\_Ginderacht](https://avatars.discourse-cdn.com/v4/letter/s/b782af/32.png) [@Serge\_van\_Ginderacht](https://forum.ansible.com/u/Serge_van_Ginderacht)\
**Post date:** [April 5, 2013, 9:26pm UTC](https://forum.ansible.com/t/trigger-task-sequences-in-handlers/12638/1 "2013-04-05T21:26:04Z")

</div>

> I've been wondering what's the best way to trigger a series of actions  
> when a handler is notified.
> 
> A good example for the need for this is deploying a web service from a  
> local checkout. What I do in this case:
> 
> 1. Prepare a tar file locally if any of the source files changed

Ideally, your development environment should build an updated tar ​​when  
code is updated. This does not seem to be a task for ansible, to me. Unless  
maybe in an automated, asynchronous way, triggered by a commit, and  
unrelated to your regular playbook.

2. Use the \*copy\* module to copy the tar file

> 

register this task:  
&nbsp;&nbsp;&nbsp;register: register\_copy​​

Now comes the fun part - if the tar file was updated on the server, I would

> like to trigger a sequence of actions. For instance:

Did you consider implementing those next steps as much as possible in an  
idempotent way.​?​​

1. Untar

> 

when\_changed: $register\_copy​​  
after this checking of the untar changed anything is a pain, a problem I  
didn't fix myself yet. Writing a 'zip/unzip/tar/untar' module would be  
nice, but I'm not sure this is easy to do in an idempotent way.

2. Reinstall requirements for the new package

> 

This really needs to be done in an idempotent way so it's not a problem to  
rerun this steps several times.

3. Restart the appropriate services

> 

This should be a handler.  
​​

> 4. Possibly some more actions on the web front-end or accompanying services

Possibly this, too.  
​​

> Implementing this as a trigger/subscribe linked list is extremely tedious  
> and verbose. What would have made this a lot simpler is something like this:
> 
> - name: copy tar  
> &nbsp;&nbsp;action: copy src=... dest=...  
> &nbsp;&nbsp;notify: reinstall  
> ...  
> handlers:  
> &nbsp;&nbsp;&nbsp;- name: reinstall  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;include: reinstall\_tasks.yml

It would indeed be nice to \*group handlers\*, though.​​  
And as handlers are basically just tasks, why not be able to include a task  
(list)?

&nbsp;&nbsp;&nbsp;&nbsp;Serge