Awx: Allow (full) extra variable access in custom notification messages

[christian-steinmeyer]

ISSUE TYPE

• Feature Idea

SUMMARY

I have a template that is configured to be triggered via (Gitlab) webhook. In the job overview, it's possible to inspect the EXTRA VARIABLES, that contain tower_webhook_payload (among others). I would like to access this information in a custom notification. I would like to be able to access the information through any of these suggestions:

{{ tower_webhook_payload.my_value }}
{{ job.tower_webhook_payload.my_value }}
{{ extra_variables.tower_webhook_payload.my_value }}
{{ job.extra_variables.tower_webhook_payload.my_value }}
{{ extra_variables.my_value }}
{{ job.extra_variables.my_value }}

---

Side note: It's not 100% clear to me, how I would access a specific element of a list. Currently, there only seems to be the summary_fields.labels attribute that consists of a list. But by including tower_webhook_payload, additional ones might be introduced (in my case commits). Would it be as easy as to use commits[0] and commits[-1] for using the first and last values in the list or how could this be achieved?

---

(I am aware that you can't guarantee that these fields exist as they depend on the incoming webhook, but I noticed that using summary_fields.created_by with a job triggered by webhook also fails (silently).)

[wenottingham]

We explicitly whitelist these due to a) sensitive values b) size considerations. I don't know that allowing the full objects makes sense here.

[christian-steinmeyer]

Thanks for the reply. When you say "we explicitly whitelist these", do you mean you whitelist the extra variables in the job (but nowhere else) or something else? Do you mean "whitelist" as in explicitly make available? And do you mean the extra variables by "these"?

I don't quite follow why sensitive values could be a problem. Do you think there are use cases in which the person that customizes notifications either should not access any of those values or could be unaware of the implications? Since I'm suggesting simply the availability of said values, they don't have to be used and any "risk" I see with the user, that you could address by making it a conscious choice (e.g. through a checkbox with use extra variables that comes with an info box on implications) but in the end leave it to the user?

If you are worried about making all extra variables available but are less sceptical about the contents of the incoming webhook (tower_webhook_payload), this would already be quite helpful.

Perhaps I could elaborate on my use case: we have a girl's repository with a playbook. When we push changes to the default branch, we want to trigger the template in tower via webhook. Now we also want to send out notifications to MS Teams about job outcomes. We'd like to include data from the incoming webhook like who made the last commit and a link to that commit for quick access directly from the card displayed in MS Teams.

[wenottingham]

Thanks for the reply. When you say "we explicitly whitelist these", do you mean you whitelist the extra variables in the job (but nowhere else) or something else?

Fields available for notifications are specifically whitelisted. See https://github.com/ansible/awx/blob/devel/awx/main/models/notifications.py#L265

[christian-steinmeyer]

May I ask whether there is any other way of accessing the information I need for my use case in a notification? If there isn't, would you consider whitelisting any subset of the extra variables fields that would suffice? I understand that you want to avoid problems, but not being able to do this, when in theory everything is "there" really feels like a limitation that could be avoided.

[wenottingham]

The way you'd have to do it right now is have your playbook do something like:

   set_stats:
     data:
        stuff: {{ tower_webhook_payload }}

and then use the artifacts object in your notification, and pull stuff out of that.

[tp199314]

Hi there,

at first, thank you very much for this helpful discussion.

I tried your solution @wenottingham this is the result:
"Failed to update notifier. Field 'artifacts' unavailable.

I added to the "Success message body" the following line:
{{ artifacts }}

We are on AWX 12.0.0 and Ansible 2.9.9. Is this an issue?

[christian-steinmeyer]

@tp199314 AWX 12 does not have the artifacts field yet. We upgraded to 15 (it was introduced somewhere in between) and can now access it. If you upgrade, make sure to make (at least one) backup of your postgres db and read up a little before going through with it. Our update took a couple tries...