Actions
You can optionally configure Actions that execute when a release goes live.
Some actions support variables. The following variables are always available:
- release - a JSON object of the release along with all metadata about the release
- releaseId - the ID of the release object
- branchId - the ID of the release branch
- snapshot - the ID of the snapshot that was generated after merge
The following Actions are supported:
- Send Email
- Fire Web Hook
For each action, you need to provide a configuration JSON block that informs the action of how to run. Here are
a few examples:
Send Email Release Action
Sends an email to one or more recipients. For a full breakdown of configuration options, read about the
Send Email Action.
A sample configuration may look like this. Note that we use the ${release}
variable to pass along the ID of
the release within the email.
{
"to": "bob@uncle.com",
"subject": "A release was triggered for UA: ${release._doc}",
"body": "Information about the release"
}
Send a Slack Message Release Action
Sends a slack message to a configured channel. For information about the action, read about the Send a Slack Message Action.
Sample configuration:
{
"url": "https://hooks.slack.com/services/SLACK/SLACK/SLACK",
"message": "A release was triggered for UA: ${release._doc}"
}
Fire Web Hook Release Action
Fires a remote web hook over HTTP. This makes a call to an HTTP endpoint when a release has gone live. For a
full breakdown of configuration options, read about the Web Hook Action.
A sample configuration may look like this:
{
"method": "POST",
"url": "https://internal.mycompany.com/publish"
}
The Web Hook endpoint will receive a JSON payload with the variables for the release.
{
"release": {
... release metadata
},
"releaseId": "",
"branchId": "",
"snapshotId": ""
}
The headers for the request will include the following:
- CLOUDCMS_BRANCH - the ID of the snapshot branch
- BRANCH - the ID of the snapshot branch
- branchId - the ID of the snapshot branch
These are sent in triplicate with different names. This is to more effectively support different virtualized
preview servers and custom endpoints that customers have built. The Cloud CMS Application Server supports
all three of these headers. The preferred header going forward is CLOUDCMS_BRANCH
.