DORA Metrics Configuration#

Overview#

DevLake computes the four DORA metrics (Deployment Frequency, Lead Time for Changes, Change Failure Rate, Mean Time to Restore) by combining data from three plugins: GitHub (or another CI/CD source), refdiff, and dora. Configuration happens primarily on the GithubScopeConfig for individual repos, then flows through a multi-stage pipeline.

GitHub Scope Config: Key DORA Fields#

The GithubScopeConfig (stored in _tool_github_scope_configs) holds three regex fields that drive deployment classification:

These are compiled into a RegexEnricher during PrepareTaskData in impl.go.

The scope config also holds a Refdiff field — a free-form JSON map passed directly to the refdiff plugin (see below).

How Patterns Are Applied: CICD Extractors#

Both workflow-run and job extractors consume the RegexEnricher from GithubTaskData:

• Workflow runs (ExtractRuns): Type is set via ReturnNameIfMatched(DEPLOYMENT, run.Name); Environment via ReturnNameIfOmittedOrMatched(PRODUCTION, run.Name, run.HeadBranch).
• Jobs (ExtractJobs): same pattern, matching against job.Name only.

ReturnNameIfMatched returns the label name if the regex matches, or "" otherwise. ReturnNameIfOmittedOrMatched returns the label unconditionally when the regex is absent — meaning an empty ProductionPattern tags every deployment as production.

Refdiff Configuration#

The Refdiff JSON map in GithubScopeConfig is passed as-is to the refdiff plugin in a separate pipeline stage added after the GitHub collection stage 1. A repoId key is injected automatically using the domain-layer ID for the repo.

Refdiff's RefdiffOptions recognises:

CalculateTagPattern queries all refs, applies the regex, sorts, and trims to tagsLimit. CalculateCommitPairs converts both explicit pairs and tag-derived pairs into commit SHAs, deduplicating as it goes.

Refdiff populates the commits_diffs table, which the DORA plugin reads to trace which commits reached production.

DORA Plugin Pipeline#

The DORA plugin is a project-scoped metric plugin 2 that orchestrates a three-stage pipeline 3:

Stage 1 — runs three subtasks 4:

• generateDeployments: builds cicd_deployments from CI/CD pipelines classified as type DEPLOYMENT.
• generateDeploymentCommits: creates cicd_deployment_commits linking commits to deployments.
• enrichPrevSuccessDeploymentCommits: links each deployment commit to the previous successful one (needed to bound the commit diff range).

Stage 2 — calls the refdiff plugin's calculateDeploymentCommitsDiff to fill commits_diffs with all commits between consecutive deployments.

Stage 3 — metric calculation:

• calculateChangeLeadTime: joins commits_diffs with pull requests to sum coding time + pickup time + review time + deploy time.
• ConvertIssuesToIncidents 5 and ConnectIncidentToDeployment 6: link incidents to the nearest prior production deployment (Change Failure Rate / MTTR).

Change Lead Time decomposition#

The metric is calculated by calculateChangeLeadTime as:

The deploy-time lookup filters for PRODUCTION environment and successful result, joined via commits_diffs 7.

Configuration Checklist#

To enable full DORA metrics for a GitHub repo:

1. Set DeploymentPattern in the repo's Scope Config to match workflow or job names that represent deployments (e.g., deploy, release).
2. Set ProductionPattern if you have non-production environments to exclude (leave empty to treat all deployments as production).
3. Set Refdiff JSON in the Scope Config with tagsPattern/tagsLimit/tagsOrder or explicit pairs to enable commit-diff calculation between releases.
4. Ensure the CICD domain type is included in the repo's Scope Config entities so GitHub Actions data is collected.
5. Associate the repo with a DevLake Project (ProjectName in DORA's options), as calculateChangeLeadTime filters PRs by project.

Key Source Files#