Processing rules

Processing rules describe how Prodgator should treat matching pipeline events: suppress a notification, escalate it, tag it, or change a field.

Current statusCopy Anchor Link

Processing rules are not applied to incoming events yet. Today you can:

• Create rules and turn them on or off on the Adapters & Rules page, Processing Rules tab (needs the Manage custom adapters permission).

Until rules run on live events, they do not change runs, notifications or deliveries.

The New Rule dialog sets a rule's name, description and priority. The app has no editor for conditions and actions yet, and no way to test a rule against a sample event. The public API does not cover rules.

How a rule is evaluatedCopy Anchor Link

A rule has:

1. Scope: which providers, repositories and event types it applies to.
2. Conditions: checks on the event's fields. All must match.
3. Actions: what to do when it matches.
4. Priority: lower numbers run first.
5. Stop processing: when true, no later rule runs after this one matches.

For an event, the engine:

1. Takes the organization's enabled rules in priority order.
2. Skips rules whose scope does not cover the event.
3. Checks each remaining rule's conditions.
4. Runs the actions of each rule that matches, and collects side effects (suppress, escalate, tag, priority).
5. Stops early after a matching rule with stop processing set.

Side effects are collected and applied after all rules run, so one rule's side effect does not change what a later rule sees.

ExampleCopy Anchor Link

Suppress notifications for a nightly build that is expected to fail:

{
  "name": "Quiet nightly build",
  "priority": 100,
  "enabled": true,
  "scope": { "repositories": ["my-org/legacy-app"] },
  "conditions": [
    { "type": "field_equals", "field": "workflowName", "value": "nightly-build" }
  ],
  "actions": [
    { "type": "suppress_notification" }
  ],
  "stopProcessing": false
}

See Writing rules for every condition and action.