Parsing rules

What DevPulse recognizes in Slack messages.

PR URL patterns

The parser auto-detects PR links from these providers:

bitbucket.org/{workspace}/{repo}/pull-requests/{id}github.com/{org}/{repo}/pull/{id}gitlab.com/{path}/-/merge_requests/{id}   (subgroups supported) dev.azure.com/{org}/{project}/_git/{repo}/pullrequest/{id}

Both bare URLs and Slack-wrapped forms (<url|display>) are accepted. Multiple PRs in one message produce multiple events.

Keywords

Action	Matches
`approved`	`approved`, `lgtm`, `+1` (case-insensitive)
`merged`	`merged`, `merging`
`deployed`	`deployed on/to/in <ENV>` — captures ENV name
`sprint_start`	`new sprint has been started`

Action precedence

A single message can express multiple states. We pick the highest-precedence action that applies, and emit an extra deployed event if the message says both:

merged  >  approved  >  opened  >  deployed

Example: merged and deployed on PROD <url> → emits both a merged event and a deployed event for the same PR.

Ticket IDs

Any uppercase project key followed by a number is captured: WEB-1142, MOB-318, API-2204. Pattern: /\b[A-Z]{2,}-\d+\b/. Tickets inside URLs are ignored (false-positive guard).

Status precedence on the PR projection

Once a PR is merged, it stays merged — later activity won't downgrade it. Approvals only override pending.

Idempotency

Every Slack event has a UNIQUE constraint on (workspace, channel, ts). If Slack retries the same message, the second hit is silently ignored.