Ansible Tower 3.6: Approval Nodes, Webhook Triggers, and What Changed

Originally reported by devclass.com. Published 2019-11-27.

What Is Ansible Tower?

Ansible Tower is Red Hat’s web-based control plane for Ansible automation. It adds a graphical interface, role-based access control, a REST API, job scheduling, and centralised logging on top of core Ansible. Tower is also the primary component of the Ansible Automation Platform, which Red Hat announced and made generally available shortly before this 3.6 release.

Approval Nodes: Manual Gates Inside Automated Workflows

The headline feature of Tower 3.6 is the introduction of approval nodes in workflow job templates. Before this release, workflows executed their node sequences automatically from start to finish. Approval nodes let you insert a deliberate pause at any point in the workflow graph, requiring a human to explicitly approve or deny before execution continues.

Typical use cases include:

• Change advisory board (CAB) gates – halt a deployment until a change ticket has been reviewed.
• Environment promotion – require sign-off before pushing artefacts from staging to production.
• Destructive-operation confirmation – pause before a database migration or infrastructure teardown.

When the workflow reaches an approval node, Tower halts and sends a notification. An authorised user can then log in to the Tower UI or call the REST API to approve or deny the request. Denying terminates the workflow branch; approving allows the next node to execute.

GitHub and GitLab Webhook Integration

Tower 3.6 adds native webhook support for GitHub and GitLab events. This means you can configure a repository to POST an event payload directly to Tower, which then triggers a workflow or individual job template without any intermediary CI system.

Common scenarios enabled by this integration:

• Kick off a deployment pipeline on a push to the main branch.
• Trigger infrastructure provisioning from a pull-request merge event.
• Run compliance checks whenever a repository tag is created.

Tower exposes a unique webhook URL per job template or workflow, and validates incoming requests using a shared secret, reducing the risk of unauthorised triggers.

Customisable Notifications

Notifications in Tower 3.6 can now be customised with additional detail. Teams can include dynamic fields drawn from the job run itself — such as job status, inventory name, or extra variables — directly inside notification messages. This makes alerts sent to Slack, email, PagerDuty, or other configured endpoints more actionable without requiring recipients to log in to Tower for context.

Experimental: OpenShift-Based Job Execution

Tower 3.6 ships an experimental capability to delegate automation job execution to an OpenShift cluster. When configured, Tower can spin up a pod to run the automation task and tear it down once the job completes. The intent is to provide on-demand, elastic execution capacity rather than relying solely on Tower’s own execution nodes.

Because this feature is labelled experimental, it should not be relied upon for production workloads without thorough testing in your environment.

Breaking Changes and Migration Notes

Tower 3.6 removes several previously deprecated items. If you are upgrading from an earlier version, review the following before proceeding:

Tower API v1 Removed

The /api/v1/ endpoint has been removed entirely. All API clients and scripts must be updated to use /api/v2/. This affects any tooling, integration scripts, or third-party applications that still reference the v1 base path.

Credential Field Endpoints Removed

The credential field on job template API endpoints and the corresponding credential field on workflow job template nodes have been removed. These were deprecated in favour of the multi-credential model introduced in earlier releases. Update any automation that sets credentials through these fields to use the credentials list endpoint instead.

tower-cli Replaced by awx CLI

The tower-cli command-line tool has been superseded by the new awx CLI. The two tools differ in command structure and authentication handling, so existing shell scripts or CI pipeline steps that call tower-cli will need to be rewritten for awx. Check the official AWX project documentation for the updated command reference.

Summary of Changes

Teams running Ansible Tower in regulated environments or with manual change-control processes will find approval nodes the most impactful addition in this release. The webhook integration reduces the need for a separate CI server to bridge SCM events to Ansible automation, simplifying pipeline architecture for teams already invested in Tower.