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
• Auto Retrigger

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. 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.

You can also use variables to access data from the response to your webhook calls.

Auto-retrigger

The event that triggered a webhook might be overrided when another event occurs.

Consider the case of a webhook that gets triggered on a test failure. If the tests starts passing in later runs, you might not have to perform the downstream actions. The auto-retrigger feature helps you to send another payload to your downstream tools in such scenarios.

This feature can save you time and effort by reducing unnecessary tickets and messages from your downstrream tools.