Webhook Listeners

Webhook Listeners are groovy scripts which are executed when a specific event(s) are executed within FlexDeploy. Each Webhook Listener is associated with one or more event types and multiple Listeners can be listening to the same event. For example you could have one Listener that sends a Slack notification and another that sends an email for the ‘Workflow Completed’ event.

View Webhook Listeners

Access event listeners by navigating to Administration → Integrations → Outgoing Webhooks.

 

Creating/Editing Webhook Listeners

To create a new Webhook Listener, click the Create Listener button. To view or edit a Webhook Listener, click on the name of the event listener.

Field

Description

Field

Description

Name

The name of the listener

Description

The description of the listener

Active

Whether or not the listener is active (Defaults to Yes)

Events

The events you want your listener to subscribe to

Groovy Script

The groovy script for the listener will be executed when a corresponding even type is executed within FlexDeploy. The editing window has capabilities for undo, redo, find, find and replace, and go to line. There are a variety of Webhook Context Variables and Methods available to use in this script. Type ‘Ctrl + space’ in the editor for suggestions on variables and methods that can be used. See more examples of listeners on our https://flexagon.atlassian.net/wiki/spaces/FD54/pages/2078605353 page.

Filter

Webhook Listeners also allow you to filter which events that the listener will process by using groovy script. The groovy script will return true when the listener should process the event and false otherwise. You are able to use all of the Webhook Context Variables and Methods that can be used in the event listener groovy script. This allows the filter to be very robust and your listener to only process the exact events that you want. For example, you can specify that you want your workflow completed listener to only process a workflow that has failed a deployment on your Dev environment and ignore all other workflow events.

If the filter script has an error or doesn’t returns something other than a boolean value it will be treated as returning false and nothing will be allowed through the filter