Skip to content

Trigger Provider

Overview

Trigger Providers define methods for receiving and processing triggers that create work orders in Digital Rebar. They are read-only objects provided by the server or trigger plugins that specify how triggers are invoked (webhooks, scheduled events, system events).

Trigger Providers work with Trigger objects to automate work order creation based on external events, time schedules, or system conditions.

Prerequisites

  • Digital Rebar Provision endpoint with appropriate permissions
  • drpcli installed and configured
  • Understanding of Triggers and Work Orders

Architecture

A Trigger Provider defines:

  • Method: HTTP method for webhook-based providers (typically POST)
  • URL endpoint: Generated webhook URL (unless NoURL is true)
  • Parameters: Required and optional parameters for trigger configuration
  • Integration logic: How incoming requests/events are processed

When a Trigger Provider receives an event:

  1. Event data is validated against required/optional parameters
  2. Trigger object is matched to the provider
  3. Work order is created using the trigger's blueprint and configuration
  4. Work order executes on available runners

Common Use Cases

Time-Based Automation

Use cron-trigger for scheduled tasks.

Example: Run maintenance tasks every night at 2 AM

Bash
drpcli triggers create - <<EOF
{
  "Name": "nightly-maintenance",
  "TriggerProvider": "cron-trigger",
  "Blueprint": "maintenance-workflow",
  "Params": {
    "cron-trigger/schedule": "0 2 * * *"
  }
}
EOF

Webhook Integration

Use webhook-based providers for external service integration.

Example: GitHub push webhook triggers content rebuild

Bash
# Get the webhook URL
drpcli triggers show github-content-rebuild | jq -r '.Meta.URL'

# Configure in GitHub repository settings:
# Settings > Webhooks > Add webhook
# Payload URL: https://drp-endpoint/api/v3/triggers/github-content-rebuild
# Content type: application/json
# Events: Push events

Create the trigger:

Bash
drpcli triggers create - <<EOF
{
  "Name": "github-content-rebuild",
  "TriggerProvider": "github-trigger-webhook-push",
  "Blueprint": "content-publish",
  "Params": {
    "github-trigger-webhook-push/repository": "myorg/myrepo"
  }
}
EOF

Event-Based Triggers

Use event-trigger for DRP internal events.

Example: Trigger workflow when machine enters specific stage

Bash
drpcli triggers create - <<EOF
{
  "Name": "stage-change-handler",
  "TriggerProvider": "event-trigger",
  "Blueprint": "post-stage-workflow",
  "Filter": "Stage=production-ready",
  "Params": {
    "event-trigger/event-type": "machines.update"
  }
}
EOF

Available Trigger Providers

Time-Based

  • cron-trigger: Execute on cron schedule

Required Parameters: cron-trigger/schedule

Event-Based

  • event-trigger: DRP internal events (machine updates, job completion, etc.)

Required Parameters: event-trigger/event-type

Version Control Webhooks

  • github-trigger-webhook-push: GitHub repository push events
  • github-trigger-webhook-pr: GitHub pull request events
  • gitlab-trigger-webhook-push: GitLab repository push events
  • git-lab-trigger-mr-webhook: GitLab merge request events
  • bitbucket-trigger-webhook-push: Bitbucket push events
  • bitbucket-trigger-webhook-pr: Bitbucket pull request events
  • vsts-trigger-push-webhook: Azure DevOps push events
  • vsts-trigger-pr-webhook: Azure DevOps pull request events

Monitoring & Alerting

  • prometheus-trigger-alert-webhook: Prometheus AlertManager webhooks
  • datadog-trigger-alert_webhook: Datadog alert webhooks
  • azure-monitor-trigger-alert-webhook: Azure Monitor alerts
  • pager-duty-trigger-incident_webhook: PagerDuty incidents
  • dynatrace-trigger-alert_webhook: Dynatrace alerts
  • zabbix-trigger-webhook: Zabbix alerts
  • logic-monitor-trigger-alert-webhook: LogicMonitor alerts
  • app-optics-trigger-alert-webhook: AppOptics alerts
  • oci-monitoring-trigger-alert-webhook: OCI Monitoring alerts
  • pingdom-trigger-webhook-alert: Pingdom alerts
  • sumologic-trigger-alert-webhook: Sumo Logic alerts
  • logzio-trigger-alert_webhook: Logz.io alerts
  • epsagon-trigger-alert_webhook: Epsagon alerts
  • prtg-trigger-post-notification: PRTG Network Monitor notifications

Collaboration & Workflow

  • slack-button-trigger-webhook-button: Slack interactive button webhooks
  • jira-trigger-new-issue-webhook: JIRA new issue events
  • jira-trigger-issue-update-webhook: JIRA issue update events
  • zendesk-trigger-webhook: Zendesk ticket events
  • monday-trigger-status_update_webhook: Monday.com status updates

Form & Automation Tools

  • zapier-trigger-webhook-post: Zapier webhooks
  • elementor-trigger-form-submit: Elementor form submissions
  • unbounce-trigger-webhook-submit: Unbounce form submissions
  • json-trigger-webhook: Generic JSON webhook
  • send-grid-trigger-event: SendGrid email events

Security & Identity

  • okta-trigger-alert: Okta security alerts
  • okta-trigger-verify: Okta verification webhooks
  • kaholo-trigger-lacework-alert-webhook: Lacework security alerts

Procedures

List Available Trigger Providers

Bash
drpcli trigger_providers list

Filter by name pattern:

Bash
drpcli trigger_providers list | jq '.[] | select(.Name | contains("github"))'

View Trigger Provider Details

Bash
drpcli trigger_providers show cron-trigger

Get Webhook URL

For webhook-based providers, retrieve the generated URL:

Bash
drpcli triggers show my-trigger | jq -r '.Meta.URL'

Creating a Custom Trigger Provider

Custom trigger providers are typically created via plugins. This example shows the structure.

Plugin YAML Definition:

YAML
---
Name: custom-alert-trigger
Description: Custom alerting system webhook
Method: POST
RequiredParameters:
  - custom-alert-trigger/alert-severity
  - custom-alert-trigger/alert-source
OptionalParameters:
  - custom-alert-trigger/alert-name-pattern
  - custom-alert-trigger/tags
Meta:
  color: orange
  icon: bell
Documentation: |
  Receives alerts from custom monitoring system.

  Webhook payload must include:
  - severity: alert severity level
  - source: alert source identifier
  - timestamp: ISO8601 timestamp

Using the Custom Provider:

Bash
drpcli triggers create - <<EOF
{
  "Name": "custom-alerts",
  "TriggerProvider": "custom-alert-trigger",
  "Blueprint": "alert-response-workflow",
  "Filter": "Available=true",
  "Params": {
    "custom-alert-trigger/alert-severity": "critical",
    "custom-alert-trigger/alert-source": "production-cluster"
  }
}
EOF

Validation

Verify Trigger Provider Exists

Bash
drpcli trigger_providers exists cron-trigger && echo "Provider available"

Test Webhook Trigger

Send test payload to webhook URL:

Bash
WEBHOOK_URL=$(drpcli triggers show my-webhook-trigger | jq -r '.Meta.URL')
curl -X POST "$WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -d '{"test": "payload"}'

Check work orders created:

Bash
drpcli work_orders list | jq '.[] | select(.Blueprint=="my-blueprint")'

Verify Cron Trigger Schedule

Validate cron expression syntax:

Bash
drpcli triggers get my-cron-trigger param cron-trigger/schedule

Troubleshooting

Trigger Not Firing

Check trigger configuration:

Bash
drpcli triggers show my-trigger

Verify: - TriggerProvider name is correct - Required parameters are set - Filter matches intended machines/conditions

Check trigger provider availability:

Bash
drpcli trigger_providers show <provider-name> | jq .Available

Webhook Returns 404

Verify trigger exists and URL is correct:

Bash
drpcli triggers list | jq '.[] | {Name, URL: .Meta.URL}'

Check endpoint accessibility:

Bash
curl -v https://your-drp-endpoint/api/v3/triggers/your-trigger-name

Work Orders Not Created

Check runner availability:

Bash
drpcli machines list WorkOrderMode=true Runnable=true

Verify blueprint exists:

Bash
drpcli blueprints exists <blueprint-name>

Review trigger logs:

Bash
drpcli events watch triggers

Parameter Validation Errors

List required parameters for provider:

Bash
drpcli trigger_providers show <provider-name> | jq .RequiredParameters

Verify all required parameters are set:

Bash
drpcli triggers show <trigger-name> | jq .Params

Field Reference

Field Definition
Description Description is a string for providing a simple description
Documentation Documentation is a string for providing additional in depth information.
Meta Meta contains the meta data of the object.

The type of this field is a key / value map/dictionary.
The key type is string.
The value type is also string.

The general content of the field is undefined and can be an arbritary store.
There are some common known keys:

color - The color the UX uses when displaying
 icon - The icon the UX uses when displaying
* title - The UX uses this for additional display information. Often the source of the object.

Specific Object types use additional meta data fields. These are described at:
https://docs.rackn.io/stable/redirect/?ref=rs_object_metadata
Method Method defines the method used on that URL
Name Name is the key of this particular TriggerProvider.
required: true
NoURL NoURL indicates that a URL should NOT be created
OptionalParameters OptionalParameters define the optional values that can be in Params on the Trigger
Params Params holds the values of parameters on the object.

The field is a key / value store of the parameters.
The key is the name of a parameter. The key is of type string.
The value is the value of the parameter. The type of the value is defined
by the parameter object. If the key doesn't reference a parameter, the
type of the object can be anything.

The system will enforce the named parameter's value's type.

Go calls the "anything" parameters as "interface {}". Hence, the type
of this field is a map[string]interface{}.
Profiles Profiles is an array of profiles to apply to this object in order when looking
for a parameter during rendering.
RequiredParameters RequiredParameters define the values that must be in Params on the Trigger

References