Continuous integration within Gearset is a powerful tool, but what if you need to trigger third-party services as part of your release process?
Outgoing webhooks allow you to automate this process, so you can kick off Selenium tests (for example) if your CI job runs successfully.
Any service with an API can be triggered directly from within Gearset.
Setting up a CI job with outgoing webhooks
To create a CI job with outgoing webhooks, start by following the usual setup process. On the Outgoing webhooks tab you can add the URL you’d like Gearset to POST to, and select which events you would like the webhook to trigger on.
When the CI job finishes, we'll send a POST request with your chosen payload to the outgoing webhook URL.
Multiple outgoing webhooks are supported, so you can simultaneously trigger various services to create more customized flows. You can add descriptions to keep track of each outgoing webhook.
Payloads
Gearset's standard payload includes information about the CI job and run. This article has more information about the standard payload.
With a custom payload, you can choose:
whether to include a
Basic Authenticationor anAuthorizationHTTP request headerFor example, a lot of providers will reply with a status code of 401 to indicate 'unauthorized' if you don't provide the relevant token here, with some expecting a particular format such as '
Bearer <Token>'.
the payload format, either
application/jsonorapplication/xmlthe payload body
Custom payloads don't add any information about the CI job or run, so you'll need to add any details to your payload.
Variables
You can use template variables to include details about the CI job and run to your custom payload. These variables are filled when Gearset sends the POST request.
Variables are referenced using the {{VARIABLE_NAME}} syntax. The following variables are available:
Variable name | Description |
JOB_ID | Gearset's CI job ID |
JOB_NAME | Gearset's CI job name |
JOB_TYPE | Gearset's CI job type |
DEPLOYMENT_ID | Gearset's CI job run deployment package ID |
RUN_ID | Gearset's CI job run ID |
RUN_STARTED_AT_UNIX_MS | Timestamp indicating when the run started as miliseconds since unix epoch |
RUN_FINISHED_AT_UNIX_MS | Timestamp indicating when the run finished as miliseconds since unix epoch |
RUN_SUCCESSFUL | A boolean indicating whether the job run was successful or not |
RUN_SUMMARY_TEXT | A message containing a summary of the CI job run, including the type of job, it's source and target and whether it was successful or not |
RUN_SUMMARY_URL | A url to check the job run details in Gearset |
RUN_TRIGGERED_BY | The name of who triggered the CI job run in Gearset |
JOB_SOURCE | The source for Gearset's CI job |
JOB_SOURCE_TYPE | The type of the source for Gearset's CI job (e.g. Git branch, Production Salesforce org) |
JOB_TARGET | The target for Gearset's CI job |
JOB_TARGET_TYPE | The type of the target for Gearset's CI job (e.g. Git branch, Production Salesforce org) |
SOURCE_COMMIT_ID | When the source of the CI job is a Git branch, this contains the Git commit hash that was used as the source of the CI run. |
SOURCE_COMMIT_AUTHOR_EMAIL | When the source of the CI job is a Git branch, this contains the email of the commit author. |
SOURCE_COMMIT_AUTHOR_NAME | When the source of the CI job is a Git branch, this contains the name of the commit author. |
SOURCE_COMMIT_VCS_URL | When the source of the CI job is a Git branch, this contains a url to check the commit in your version control system. |
This example shows an outgoing webhook that uses a custom payload with the SOURCE_COMMIT_ID variable. When the CI job finishes and triggers the webhook, the variable is replaced with the source branch's commit hash.
Common Integrations
Many customers look to integrate Outgoing Webhooks from Gearset with a selection of common 3rd party tools. Here are some useful resources to help you set up your integrations with these platforms.
Slack
Gearset offers out of the box integration with Slack notifications. Our default integration, containing dynamic information about your CI jobs, can be configured on the Notification settings tab, after running through this guide.
However, customized static content can also be sent to Slack by configuring an outgoing webhook. You'll need to begin by creating an Incoming webhook URL from Slack, and then adding whatever content you would like as a JSON formatted payload. The Slack webhook URL already contains an authentication secret, so no additional authentication needs to be provided.
Azure DevOps
To trigger events in Azure DevOps, you will need to use their public REST API. Once you have found the appropriate POST endpoint, add that to the URL field. You will then need to generate a custom JSON payload based on the chosen endpoint's documentation.
Customers often want to queue a build in Azure DevOps once a CI job has succeeded - this REST API endpoint is documented here.
Azure DevOps' REST API requires authentication - you will need to create a Personal Access Token (PAT) with appropriate permissions. Then, Base64 encode your username and PAT following the instruction here. Select Authorization as the authentication type for the outgoing webhook, and add the Base64 encoded string to the credentials field.
Provar Testing
You can execute tests in Provar at the end of a CI run by setting up an integration with Provar Manager, or by triggering a custom Jenkins CI server job.
Tricentis Test Automation for Salesforce
You can execute tests in Tricentis Test Automation for Salesforce at the end of a CI run using their public REST API.
Is a guide for your integration missing? Let us know!