I’m planning to run 10 scripts through 10 different job templates (yml playbooks). They should run in a sequential order dependent on each. Only if the job succeeds, next job should run. In case if it fails, it should trigger an email and notify where the affected playbook may/may not be modified and the job will be run again. And this should resume the sequence of jobs but can’t re-run any of the already succeeded ones.
For example, my job1, job 2, job 3 succeeded, job 4 failed and it triggered an email to respective stake holders. Now job 4 is updated with new yaml or just re-run and now it succeeds, it should next run job 5, job 6 and so on. How can this be achieved in Ansible platform. I’ve checked the documentation page. But i couldn’t find any supporting articles to show how dependency can be achieved through Job Templates.
Have anyone done this before? any insights would be helpful. Thank you.
I believe you may be able to implement this in a pretty straight-forward way if you use Workflow Templates. Are you aware of those? I’ll give you an example:
The first job will execute always, then the 2nd one will run only if the 1st ended successfully, and so forth. You can also set conditions to run the next job despite the failure of the previous one.
On the other hand, all the logic you may need (send email notifications, skip previous template jobs, etc) can be easily implemented on the playbooks themselves just using conditionals - I’ll leave that to you, but if you need help with that too I may be able to give you some examples.
Thanks for your reply. Yes, i looked at Workflow templates. But i still don’t know how to set it up for dependencies. I have created those 10 job templates. When i try to create the Workflow template i don’t see options to add the job templates i have or anything to specify the order of execution. By any chance do you have an example that you can share?
Can I ask you to tick the solved check on the post you believe was most helpful? This way other ppl with the same doubts can benefit from it also. Thanks!
Hey Jordi, quick question. I’ve set up about 5 jobs templates inside my Workflow. But when one fails in the sequence, i either have option to just trigger the failed job only for not the rest of the sequence or run the entire workflow again including the already completed ones. Is there a way to re-run the failed job and the rest of the not executed ones in the workflow?
Once job 3 fails the workflow stops there. Now i have two options
Relaunch the failed job 3 (This is relaunching only Job 3 but not triggering job 4 and 5)
Relaunch the entire workflow again. (This is relaunching Job 1 & Job 2 again as well)
Is there a way that i can launch the sequence form the failed job 3? (Job3 followed by job 4 and then job 5) but without re-running the already executed ones (Job 1 & job 2)?
Hello @amjayreen I just have to go out right now, but I bookmarked your post to get a notification tomorrow, so I won’t forget. I’ll reach you back then.
Hello @amjayreen sorry for the delay. Right now I don’t have my “Ansible arsenal” at hand since I’m on a rush trip to visit a client on the other side of my country… However, I took advantage of the idle time on the airport to study the workflow templates documentation again, and I had a couple of ideas that may work for you. On the one hand, you may add tags to your JT playbooks and enable either tags or skip-tags prompts on the WJT. This way when you re-run the WJT you will be asked to specify the tags you want either to run or to skip, and even though all the JT’s will run, the tasks on their associated playbooks won’t.
On the other hand, you may also use the “on-success” and “on-fail” edge types along with the replication of the subsequent job templates for when the previous JT failed (that is, splitting the JT output in two different paths, one for when it fails and other for when it succedes). On this scenario though, you might have to add intermediate “Approval” blocks to pause the WTJ execution temporarily while you make the changes needed on the target managed nodes, etc (I don’t have many details of your use case, so I’m doing a lot of guessworking here).
Again, I’m doing all of this on my head because I don’t even have my laptop with me, but I hope you get the idea.
Anyway, if you feel that won’t work for you and you are willing to share your project details, you may send them to me either here or in a private message and I’ll try to give you more detailed examples once at home next week.
If I remember well, I did earn that one just by chatting with the discobot assistant when I joined the community. Anyway, if you visit my profile you’ll find other ways to contact me privately.
Hello again, @amjayreen! Thank you so much for your patience. I’m answering your private message here too before this thread gets closed.
Recently, I created a proof of concept (POC) demonstrating the feasibility of running a WJT recursively and automatically, devoid of any user interaction. This setup skips previously successful JT’s. Please note, this is a highly condensed proof of concept. You’ll need to customize it to fit your specific use case. Interestingly, the idea for this came from your previous message—great catch!
Now, let’s delve into the specifics:
I developed three playbooks and linked them to their JT nodes in the WJT. During the initial run, JT1 succeeded, JT2 failed, and JT3, intentionally left as a placeholder, never executed—a demonstration of rerunning JT2 while skipping JT1:
Upon the failure of the task in JT2 checking if the file’s contents != 0 (I just used a var for simplicity sake), another task within the same playbook deletes the JT1 node in WJT. Subsequently, it launches the WJT again. Here’s the proof:
It’s crucial to enable concurrent WJT execution during setup. Failure to do so will cause the execution to indefinitely wait for the first iteration to finish.
This approach is “destructive,” so if necessary, consider creating the WJT via Infrastructure as Code (IaC) using the awx.awx / ansible.controller collection. Note that these collections are interchangeable—the former for the upstream AWX and the latter for downstream AAP. You can use awx.awx against an AAP instance!
I hope this solution aligns with your needs! Although it was a bit challenging, navigating through these recursive WJT executions was quite a learning experience for me!