Getting Started with Outgoing Webhooks

This guide will walk through everything needed in order to send a slack notification on workflow failures.

Configuring Slack integration

You will first need to configure your Slack integration with FlexDeploy. To do this you will need to create a new Slack bot and create a FlexDeploy Messaging Account for Slack. To get more information on this you can follow the guide located on our Slack plugin guide. This simple configuration will allow you to send notifications to your specified Slack channel for this bot.

We will want to create a new Messaging Account for Slack. We can do this by going to Topology→ Integrations → Messaging. For the Slack provider, the only required property is the Bot Token.

Creating an Outgoing Webhook Listener

Now that Slack is integrated with FlexDeploy we will now want to create the Webhook Listener that will process all failed Workflow Completed events. To do this we will navigate to the events screen through Administration → Integrations → Outgoing Webhooks. To create a new Webhook Listener click the Create Listener button.

Add a name, event type, and mock payload to the new event listener. Also remove the default script implementation. The event type will specify what events our new listener will process, in this case the Workflow Completed event type. The mock payload is used in the groovy script editor to give suggestions when accessing the EVENT variable. Set this to the Workflow Completed payload.

Implement the Groovy Script

Now with the Webhook Listener created, we can add the groovy script to send the Slack message. FlexDeploy has several built in Event Context Variables and Methods that can be used to help you implement exactly what you want in this groovy script. We will be using FlexDeploy’s Slack methods in order to send a notification.

The below script is posting the initial message to slack and subsequently replying to that message with the plugin logs. If you only wish to send the initial message you can stop after line 15

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 //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 = "Failed Workflow Notification"; LOG.info("Running listener: ${listenerName}"); def channel = 'testing'; def slackAccountCode = 'SLACK'; //make the workflow complete message and include error data def message = SLACK.makeWorkflowCompletedMessage(EVENT.payload,true); //save the tsId so we can reply with the failed logs def tsId = SLACK.postMessage(slackAccountCode,channel,message); LOG.setMessage("Posted slack message ${tsId}"); //now get our failed plugin logs and attach them def streams = FLEXDEPLOY.getPluginLogInputStreams(EVENT.payload.workflowExecutionId); if(!streams || streams.size() == 0) { return; } def errorStream = streams.last(); //now attach the logs to our previous message SLACK.postAttachment(slackAccountCode,channel,errorStream,'Failed logs',tsId); LOG.setMessage("Posted slack message ${tsId} with logs");

As stated before you will need to add your Slack account prior to using this listener.

The ‘makeMessage’ functions on the Slack object return a FlexSlackMessage object. This object has several built in features to help format messages in a consistent way when sending from FlexDeploy. If you wish to construct your own message you can simply pass the json string to the postMessage function.

Implementing the Event Filter

We now have a Webhook Listener that will send a Slack notification to our specified channel every time a workflow is completed. In order to only send the notification when the workflow execution has failed we will need to implement a filter. The filter is groovy script that will determine whether or not our Listener will process a given event. To edit the filter we will need to click the filter tab to the left of our script tab. We will now create a groovy script that will return true when we want our listener to process the event and false otherwise.

1 2 3 def excludedProjects = [795341]; return !"SUCCESS".equals(EVENT.payload.executionStatus) && !excludedProjects.contains(EVENT.payload.project.projectId);

In this example we have also added a list of excluded projects that we do not want our listener to process even if the workflow execution has failed. The return value will check our event payload for the execution status. If the execution status is SUCCESS, or if the project Id of the workflow execution is in our excluded projects list we will return false. You can edit this filter to cater to your needs. For example, you can edit the return statement to only return true only if the workflow was a deployment and it failed when trying to deploy to Production.

Viewing Outgoing Webhook Messages

Now that we have our Webhook Listener completely set up we will create a workflow that will fail and attempt to execute it. In order to see if our filter is working correctly we will view our event messages after executing our faulty workflow. This can be found by clicking the https://flexagon.atlassian.net/wiki/spaces/FD54/pages/2091909288 button on the main events page.

On this page we should be able to see our event has been processed by our new listener in the table along with the payload that was sent. Our message states that our Slack message has been sent so we can verify that. If the message has not been sent we can debug by showing our groovy logs by clicking the show logs button and resubmit the event with the same payload by clicking the resubmit button. These tool are very useful for debugging as we can create a duplicate event without having to go back and execute our workflow.

If the event listener and Slack integration was set up correctly a message should have been sent to your channel.