Core concepts in webhooks

Understand the core concepts in Test Observability webhooks

Following are the important concepts in Test Observability webhooks:

• Event types and trigger conditions
• Default and custom payloads
• Templates
• Variables
• Retrigger webhooks when failing tests start passing again

Event types and trigger conditions

Test Observability provides the option to trigger webhooks based on four event types:

• Build Finish
• Quality Gate Result
• Test Failure
• Alert Triggered

Each of these events offers trigger conditions to narrow down cases when the webhooks are triggered. The following table lists all the filters and additional options available for these filters:

Payload body

Payload body is the data sent by the webhook to your target application. This data contains information about the event that triggered the webhook. You can choose between default or custom payloads while creating a webhook.

Default payload

Default payload is the most flexible option which you can modify according to your needs to send data to any tool of your choice.

Custom payload

The custom payload option gives you a user-friendly interface to quickly structure the payload body into headers, authorization, body, and params.

Templates

Templates provide a predefined structure for payloads tailored to specific tools like PagerDuty, OpsGenie, Jira, and Microsoft Teams. These user-friendly templates simplify the process of creating payloads, enabling seamless integration with your preferred tools in just a few clicks.

Variables

By using variables in webhooks, you can ensure that your payload body is always updated with dynamic data to configure actions in your downstream tools.

TEST_NAME, TEST_FAILURE_LOG, BUILD_STATUS, QG_RESULT, and ALERT_NAME are a few examples for variables.

Variables can be added to both payloads and webhook URLs, and they are readily accessible with just a click when creating webhooks.

Retrigger webhooks when failing tests or builds start passing again

Test Observability webhooks allow you to use variables to access data from webhook response payloads, enabling advanced features like sequencing and automatic webhook retriggering.

For instance, you can configure a webhook to trigger on a build or test failure and set up another webhook to activate when the build or test passes again.

This dynamic alerting keeps you informed about issue resolutions without requiring constant manual monitoring, making it easier to stay focused on your workflow.

Consider an example of creating a Jira ticket via webhooks whenever a build fails. You can use variables to extract information from the webhook response payload provided by Jira. This allows you to trigger another payload when the build starts passing again. By using this feature, you can automatically update the correct Jira ticket and reduce unnecessary effort.

To reference variables from the JSON response of the original webhook, you can use the following format:

{{RESPONSE.VARIABLE.PATH}}

For example, consider the following payload snippet:

{
    "id": "Test123",
}

To reference the id variable, you can use the following format:

{{RESPONSE.id}}

If you like to learn creating JSONPath, please refer to JSONPath Online Evaluator .