[Feature][Plugin] Datadog Incident Management integration

Search before asking

• I had searched in the issues and found no similar feature requirement.

Use case

As an engineering leader using DevLake for DORA metrics, I want to ingest incidents from Datadog Incident Management, so that change failure rate and time to restore service keep working after a team moves its on-call off PagerDuty and onto Datadog.

DevLake already supports PagerDuty, Opsgenie, Rootly and incident.io. Datadog is a common destination for teams consolidating monitoring, paging and incident response in one tool, and today those teams lose their incident source when they migrate. The only path left is the generic webhook plugin, which cannot carry severity history, detection timestamps or per-incident custom fields.

Description

Datadog Incident Management exposes incidents through the public API (/api/v2/incidents,
paginated). Auth is the standard Datadog pair of an API key plus an application key,
against a site-specific host (api.datadoghq.com, api.datadoghq.eu, api.us3.datadoghq.com, …),
so the connection needs an endpoint or site field like other multi-region plugins.

Proposed plugin, modeled on incidentio and rootly:

• Connection: API key + application key + site/endpoint.

• Scope: incident types, analogous to the incident-type scope in the incident.io plugin.
  A single organization-wide scope is the fallback for orgs that do not use incident types.

• Entities: incidents → domain issues with type = INCIDENT plus incidents.
  Field mapping, verified against a production Datadog organization:

  Datadog	Domain
  public_id (and slug, e.g. IR-22)	issue_key
  title	title
  severity (SEV-1…SEV-5, UNKNOWN)	severity, via a configurable mapping
  state (active / stable / resolved)	status, original_status
  created	created_date
  detected	detection timestamp, for time to detect
  resolved	resolution_date, lead_time_minutes
  customer_impacted, customer_impact_duration	impact attributes
  url	url
  is_test	excluded from collection, like incident.io's test/tutorial incidents

• Custom fields: Datadog incidents carry both default fields (detection_method,
  root_cause, services, teams) and org-defined single-select, multi-select and
  free-text fields. The plugin would collect these verbatim into the tool layer, and the
  scope config would name which field maps onto component and which onto severity.
  The same shape as the deployment-name pattern in the CircleCI scope config. This keeps
  organization-specific vocabulary out of the plugin while making the fields usable for
  change-failure attribution.

• No framework changes: the result feeds the existing DORA incident metrics.

Out of scope for a first PR: Datadog On-Call (schedules, pages, escalation policies),
monitors and alerts, and the Datadog DORA Metrics product.

We have mapped the fields above against our own production Datadog organization through
the API, and intend to implement the plugin in Go following the incidentio plugin layout
(models/raw, tool models with migration scripts, collector/extractor/converter tasks,
connection and scope APIs, e2e fixtures). Flagging the intent here first in case
maintainers want a different scope model or a different approach to the custom-field
mapping before we open the PR.

Related issues

• #9023 - incident.io plugin, the closest precedent for scope and field mapping
• #8877 - Rootly plugin

Are you willing to submit a PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct