controller_notifications.yml
In these files we configure the notifications for automation controller.
we will probably do this on production only, as we don't want mail from all environments.
variables
The api understands the folowing structure to define notification templates in controller:
{
"name": "",
"description": "",
"organization": null,
"notification_type": null,
"notification_configuration": {},
"messages": {
"started": null,
"success": null,
"error": null,
"workflow_approval": null
}
}
Below you find a basic example.
group_vars/all/controller_notifications.yml
Here we see an empty set for all.
---
controller_notifications_all: []
...
But you can already see that the variable name used here has the "_all" extension, so the variable will not be overridden as this is not quite a inventory.
Why we do this, will become clear in a moment.
group_vars/dev/controller_notifications.yml
As we do not configure extra notifications in development, this file is an empty set.
(We use the containerized setup version, so no need for notifications).
---
controller_notifications_dev: []
# No extra config exists
...
Here the variable has the "_dev" extension, so the variable will not be overridden.
group_vars/prod/controller_notifications.yml
As we only configure notifications in prod.
---
controller_notifications_prod:
- name: deploy_notification
organization: TEST
notification_type: email
notification_configuration:
host: <smtp-service-host>
password: <token>
port: <smtp-port>
recipients:
- <email address>
sender: <sender_address>
timeout: 30
use_ssl: true
use_tls: false
username: <username>
...
Here the variable has the "_prod" extension, so the variable will not be overridden.
When we run a pipeline for a certain environment, the inventory structure will provide us with 2 variables:
- controller_notifications_all
- controller_notifications_
We will merge these 2 variables into 1: controller_notifications and feed this to the infra.aap_configuration.controller_notifications role.