Webhooks module to send events to external services

[butschster]

The aim of this proposal is to introduce webhook functionality to Buggregator, enabling external notifications for various event types received by the system. This feature will allow users to configure webhooks via YAML files that define actions triggered by specific events. The proposed YAML structure for each webhook is as follows:

webhook:
  uuid: 018f0c52-7b8b-717a-9f43-210fd48d8552
  event: sentry.received
  url: https://webhook.site/507341b8-83de-40c4-8d88-cdaf0dea3047
  headers:
    X-Auth: secret
  verify_ssl: false
  retry_on_failure: true

Types of Events:

Buggregator can currently handle the following events:

• sentry
• monolog
• var-dumper
• ray
• inspector
• http-dump
• profiler
• smtp

Docker Configuration:

Webhook configurations can be mounted into the Buggregator Docker container using the following volume configuration:

buggregator-server:
  ...
  volumes:
    - ./webhooks:/app/runtime/webhooks

This setup allows for easy management and updating of webhook configurations without needing to rebuild or restart the entire container.

Execution Strategy:

Each webhook will be triggered in a separate process using the RoadRunner in-memory queue driver. This approach ensures that the main application performance is not hindered by the webhook processing tasks.

Configuration Options:

There are two main approaches to consider for managing webhook configurations within the Buggregator Docker container:

1. Single File Configuration:

   • Pros:
     • Centralized management of all webhooks, making it easier to oversee and audit.
   • Cons:
     • A single point of failure; corruption or misconfiguration in this file could disable all webhook integrations.
     • Larger file might become unwieldy as the number of webhooks grows.

2. Multiple Files Configuration (each webhook in a separate file):

   • Pros:
     • Isolates configurations, minimizing the risk where an error in one file affects others.
     • Easier to manage lifecycle of individual webhooks (create, delete, update) without affecting others.
   • Cons:
     • Could be harder to get an overview of all configured webhooks at a glance without additional tooling.

Retry Mechanism:

The retry_on_failure option is designed to attempt delivering the webhook notification up to 3 times in case of failures such as network errors, response timeouts, or server errors from the webhook URL.

Rationale for n8n Integration:

Integrating with n8n opens a multitude of possibilities for automating responses to events within Buggregator:

• Automated Alerting: Trigger emails, SMS, or chat messages based on certain event thresholds or error types.
• Issue Resolution Workflows: Automatically create tickets in project management tools like Jira or GitHub Issues when specific types of errors are reported.
• Custom Integrations: Enable custom workflows that can interact with virtually any API-driven service, providing flexibility to tailor responses specifically to the needs of your infrastructure.