Sample Webhook Listeners

Below are some sample Webhook Listener use cases and how to implement them.

The Default Listener (POST Webhook)

When creating a new Listener, the script will default to the below which simply forwards the payload via a REST Post request. This script emulates an outbound webhook in the truest sense since no payload modification or logic is done. Simply update the postUrl variable with your endpoint and its ready to go.

//Carry out any custom action you wish for this event. Check out the documentation for reference or ideas. //Optionally filter out events you dont want to execute by returning false on the filter script tab. def listenerName = "myListener"; LOG.info("Running listener: ${listenerName}"); def postUrl = ""; def responseCode = REST.forward(postUrl,EVENT); LOG.setMessage("Message forwarded (${responseCode}) to ${postUrl}");

End Release After Snapshot Deploys to Production

To take advantage of ending a release after a pipeline execution completes you can create a new listener and select the Pipeline Stage Completed. You will then need to check whether the completed stage is the final stage in the pipeline. You can do this in a number of ways. One way is shown below by checking the environment code and comparing it to our final PROD stage.

 

//Carry out any custom action you wish for this event. Check out the documentation for reference or ideas. //Optionally filter out events you dont want to execute by returning false on the filter script tab. def listenerName = "endReleaseListener"; LOG.info("Running listener: ${listenerName}"); if(EVENT.payload.environment.environmentCode.equals("PROD")){ LOG.setMessage("Release ${EVENT.payload.release.releaseName} has completed moving through the pipeline. Ending release."); FLEXDEPLOY.endRelease(EVENT.payload.release.releaseId); }

 

Another way to take advantage of this is to use the Webhook Listener’s filter. This filter is also groovy script where you can determine whether the event should be processed by the Listener. In this example, we will filter the events so that only pipeline stage completed events that have completed the Prod stage in the pipeline are allowed through.

Logically, both approaches will accomplish the same task, however, using the Filter will automatically hide it from the Outgoing Webhook Messages display. This will reduce some of the noise and allow you to easily find the messages you care about.

if(!EVENT.payload.environment.environmentCode.equals("PROD")){ return false; }else{ return true; }

Send a Slack Notification After Approval Task Is Created

This will send a notification to the specified slack channel when an approval task is created. To implement this you will simply need to set up your Slack Messaging Account and add a short script to your listener. In this example we are filtering for APPROVAL tasks only.

For a more comprehensive overview of how you can integrate Slack with your FlexDeploy Approval process check out this blog

 

Attach Failed Plugin Logs to Jira Issue

One of the bigger use cases of the Workflow Completed event is to send the logs to another application. In this particular example we are uploading the logs to the Jira Issue associated to the project. We also have a filter setup to only execute this listener for workflows with a ‘FAILURE’ status and when the Workflow Execution has Jira Issues associated.

This script uses FLEXDEPLOY.getIntegrationInstance to get a configured Jira instance within FlexDeploy. This is a great alternative to putting a plain text password in the script

 

The next step is to set up our filter to only process failed workflow completed events with Jira issue numbers.

 

Create ServiceNow Incident on Workflow Failure

In the below example we make use of the ChangeManagementSystemService to allow us to create an incident through FlexDeploy’s internal ServiceNow integration. The only thing that needs to be configured ahead of time is your ServiceNow instance in Topology->Integrations->ChangeManagement

Send Test Results to Teams

The Workflow Completed Event includes all of the test execution data for any TEST workflow type. The below example shows how this data can be used by sending a Teams message with the data neatly formatted in an html table.

Naturally you can edit the table/style in any way you wish. The below screen shot is a sample message from the listener:

Build Dependent FlexDeploy Project

This use case can be helpful when you have a FlexDeploy Project that is dependent on some other Project building first. Generally speaking you would try to handle this on the source control side of things but sometimes that just isn't possible. In the below example we are initiating a build on Project with Id 10241 only after a build has successfully completed for the Project with Id 10002.

Send email with logs on Workflow Failed

The example below makes use of the FLEXDEPLOY.getPluginLogInputStreams method to send workflow logs as attachments in an email. The message body simply consists of the json payload for the event.

This function is listening to the ‘Workflow Completed’ Event.

 

Create Teams Approval Tasks

@Since 5.5.0.2

This sample sends an interactive message to a Microsoft Teams channel that allows members of the channel to approve or reject an associated FlexDeploy task. As shown in this script, you can add conditions to handle sending to multiple different channels in one listener depending on some condition. (e.g. environment, pipeline, release, etc.) You could also apply similar logic to the webhook listener filter to customize when and where the Teams message should be sent.

See the incoming samples also. An incoming webhook is needed to capture the button clicks that users perform on the Teams messages and ultimately approve/reject the task in FlexDeploy.

Execute Utility Project

@Since 5.5.0.3

This sample executes a specific FlexDeploy Utility Project called “RunSonar”. In the script below, we are executing the “RunSonar” project whenever a Build workflow with the specified projectId completes successfully. As an extension of the executeUtility function, we can pass ExecuteOptions which allows you to configure which instances the utility project will run on and also the ability to pass inputs and flexfields values to the utility workflow. If no ExecuteOptions are passed as parameters, then the utility will execute on all instances associated in the project configuration.

This function is listening to the ‘Workflow Completed’ Event.

 

The following macros are not currently supported in the footer:
  • style