How to Distinguish Ansible and AAP

I realize that Ansible was meant to describe a target state rather than run complex algorithms. This approach simplifies uniformity on different targets. Unfortunately, some Ansible enthusiasts may encounter situations where they have different execution environments.

I posted a piece a while ago on how to unify the execution experience of a classic Ansible controller and an Ansible Tower Project. The case is when you develop a playbook that will run and behave almost identically to the job template on the Ansible Automation Platform. Now, we face the difference between execution environments on the Automation Platform and Ansible Core installation on our dedicated controllers. The root cause, as always, is security requirements.

We have already rewritten the most painful changes (thank you for moving archive/unarchive into community collection!!). Still, some of them have no workaround, and we need to understand your execution environment at the moment. The best indicator of the fact that your playbook is running as an instance of the job template is to check "magic" variables. You may find the list of Ansible Tower controller variables in the documentation. In the example below, I use the most obvious one to decide what tasks to perform.

# Community mail task is available 
- name: Send Report By Mail
  include_tasks: mail_integration.yaml
  vars:
    title: "From Ansible Automation Platform"
  when: tower_task_id is defined

# Mail is blocked, prepare files
- name: Save Report to Archive
  include_tasks: file_integration.yaml
  vars: 
    title: "Download Archive from Host"
  when: tower_task_id is undefined  
  

In conclusion, I should mention that the latest Red Hat Ansible Automation Platform is fantastic, but the new documentation is almost useless. Granted, the old one was far from perfect, but at least I can still find the information I need as a developer. Now with the AAP 2.5 documentation release, good luck finding any useful details.