Plugin for per-sub-project DORA metrics in a monorepo - #9037
Open
eyal4D wants to merge 5 commits into
Open
Conversation
…repo Repos containing multiple logically separate projects (each deployed by its own CI job, PRs tagged by label) previously collapsed into a single set of DORA numbers, since DevLake's scope model is one-scope-per-repo. Adds a new metric plugin, monorepo, that runs after dora and attributes deployments (by CI job name) and merged pull requests (by label) to a configured sub-project, writing per-sub-project deployment and change lead time metrics to two new tables. Nothing existing is modified: dora and the core scope model are untouched, and PR coding/pickup/review time are reused from dora's own project_pr_metrics rather than recomputed. Includes unit tests, an e2e test with fixtures, and Grafana dashboards (mysql + postgresql) to view the output.
Adds a Project Settings panel for the monorepo plugin, letting users define sub-projects (name, PR labels, deploy job pattern) directly in config-ui rather than only via the raw API, following the existing pattern used for the linker plugin's fields.
RunAfter() is advisory-only: core's blueprint plan builder (GeneratePlanJsonV200) merges every enabled metric plugin's plan with ParallelizePipelinePlans, which zips stages together by index and never consults RunAfter. With dora and monorepo both enabled on a project, monorepo's single stage ran concurrently with dora's first stage instead of after dora's third stage, where project_pr_metrics and cicd_deployment_commits actually get written — silently producing nil coding/pickup/review times with no error. Pads monorepo's plan with empty stages so its real work lands strictly after dora's plan completes. This is a workaround for the unenforced RunAfter contract, not a true fix; it's coupled to dora's current 3-stage plan (documented in the code). Adds a regression test locking in the padded shape, and corrects the RunAfter doc comment which previously claimed ordering was guaranteed. Verified: fresh blueprint plan generation on the rebuilt binary shows org -> dora(x3) -> [empty x3] -> monorepo; migration and e2e tests pass on both MySQL and a real Postgres instance.
…' into feature/subprojects-for-monorepo
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Repos containing multiple logically separate projects (each deployed by its own CI job, PRs tagged by label) previously collapsed into a single set of DORA numbers, since DevLake's scope model is one-scope-per-repo.
Adds a new metric plugin, monorepo, that runs after dora and attributes deployments (by CI job name) and merged pull requests (by label) to a configured sub-project, writing per-sub-project deployment and change lead time metrics to two new tables. Nothing existing is modified: dora and the core scope model are untouched, and PR coding/pickup/review time are reused from dora's own project_pr_metrics rather than recomputed.
Includes unit tests, an e2e test with fixtures, and Grafana dashboards (mysql + postgresql) to view the output.