ldraney/pal-e-dora-exporter

Fork 0

Add tier label to pal-e-dora-exporter #5

New issue

Closed

opened 2026-06-13 18:33:25 +00:00 by ldraney · 2 comments

ldraney commented

2026-06-13 18:33:25 +00:00

Owner

Type

Feature

Lineage

Migrated from ldraney/DORA#1.
Standalone — discovered during DORA project setup (2026-05-29).

Repo

ldraney/pal-e-dora-exporter

User Story

As a platform operator
I want playground repos excluded from DORA composite scores
So that metrics reflect real production health

Context

The DORA exporter currently scrapes every Forgejo repo equally. A PR merged to svelte-playground carries the same weight as pal-e-platform. This dilutes composite scores with noise. Adding a tier label at the exporter level is the foundation — Grafana filtering, per-app drill-downs, and composite scoring all depend on it.

File Targets

Files the agent should modify or create:

src/config.py — add tier config loading (YAML or env-based repo → tier mapping)
src/collectors/forgejo.py — add tier label to PR metrics
src/collectors/woodpecker.py — add tier label to deployment metrics

Files the agent should NOT touch:

Dockerfile — no changes needed
.woodpecker.yaml — no CI changes needed

Feature Flag

None required — tier label is additive and does not change existing metric behavior.

Acceptance Criteria

Exporter emits tier="1", tier="2", or tier="3" label on all 4 metric families
Config is a YAML/env-based repo → tier mapping
Tier list matches docs/tiering.md in the DORA repo
Unlabeled repos default to tier 3

Test Expectations

Unit test: config loader parses tier mapping correctly
Unit test: collectors attach correct tier label per repo

Constraints

Keep the config format simple — YAML preferred over env vars for readability
No breaking changes to existing metric names or labels

Checklist

PR opened
Tests pass
No unrelated changes

dora-metrics — project this affects
docs/tiering.md — tier definitions

### Type Feature ### Lineage Migrated from ldraney/DORA#1. Standalone — discovered during DORA project setup (2026-05-29). ### Repo `ldraney/pal-e-dora-exporter` ### User Story As a platform operator I want playground repos excluded from DORA composite scores So that metrics reflect real production health ### Context The DORA exporter currently scrapes every Forgejo repo equally. A PR merged to `svelte-playground` carries the same weight as `pal-e-platform`. This dilutes composite scores with noise. Adding a `tier` label at the exporter level is the foundation — Grafana filtering, per-app drill-downs, and composite scoring all depend on it. ### File Targets Files the agent should modify or create: - `src/config.py` — add tier config loading (YAML or env-based repo → tier mapping) - `src/collectors/forgejo.py` — add `tier` label to PR metrics - `src/collectors/woodpecker.py` — add `tier` label to deployment metrics Files the agent should NOT touch: - `Dockerfile` — no changes needed - `.woodpecker.yaml` — no CI changes needed ### Feature Flag None required — tier label is additive and does not change existing metric behavior. ### Acceptance Criteria - [ ] Exporter emits `tier="1"`, `tier="2"`, or `tier="3"` label on all 4 metric families - [ ] Config is a YAML/env-based repo → tier mapping - [ ] Tier list matches `docs/tiering.md` in the DORA repo - [ ] Unlabeled repos default to tier 3 ### Test Expectations - [ ] Unit test: config loader parses tier mapping correctly - [ ] Unit test: collectors attach correct tier label per repo ### Constraints - Keep the config format simple — YAML preferred over env vars for readability - No breaking changes to existing metric names or labels ### Checklist - [ ] PR opened - [ ] Tests pass - [ ] No unrelated changes ### Related - `dora-metrics` — project this affects - `docs/tiering.md` — tier definitions

ldraney added the

type:feature

label

2026-06-13 18:35:58 +00:00

ldraney referenced this issue from ldraney/DORA

2026-06-13 18:36:14 +00:00

Add tier label to pal-e-dora-exporter #1

ldraney commented

2026-06-13 19:16:25 +00:00

Author

Owner

Issue #5 Template Review

TEMPLATE CONFORMANCE

Template: template-issue-feature (pal-e-docs)

### Type -- present, value "Feature" is valid
### Lineage -- present, references ldraney/DORA#1 migration
### Repo -- present, correct repo ldraney/pal-e-dora-exporter
### User Story -- present, follows As/I want/So that format
### Context -- present, explains the motivation clearly
### File Targets -- present, lists both modify and do-not-touch files
### Feature Flag -- present, marked "None required" with rationale
### Acceptance Criteria -- present, uses checkbox format
### Test Expectations -- present, uses checkbox format
### Constraints -- present, non-empty
### Checklist -- present, uses checkbox format
### Related -- present, references project and doc

All 12 required sections present and non-empty.

CONTENT QUALITY

File Targets -- GOOD. All three paths verified against the repo tree on main:

src/config.py -- exists (786 bytes)
src/collectors/forgejo.py -- exists (5842 bytes)
src/collectors/woodpecker.py -- exists (4397 bytes)

Negative targets (Dockerfile, .woodpecker.yaml) also verified as existing files correctly excluded.

User Story -- GOOD. Clear, actionable, states the persona and value.

Context -- GOOD. Self-contained explanation that doesn't require external knowledge.

Acceptance Criteria -- GOOD. Testable, uses checkboxes. References docs/tiering.md for tier definitions.

Feature Flag -- GOOD. "None required" is correct -- adding a label is additive and non-breaking.

BLOCKERS

1. DUPLICATE SCOPE -- issue #2 and open PR #3 cover the same work.

Issue #2 ("Add tier label to all Prometheus metrics") was filed first and already has an open PR #3 implementing the exact same feature: adding a tier label to all metrics via a YAML config loader. PR #3 states "Closes #2".

This issue (#5) targets the same three files, describes the same user story, and has overlapping acceptance criteria. There is no mention of #2 or #3 in the Lineage, Context, or Related sections. This is a scope collision.

Resolution required -- one of:

(a) Close this issue as duplicate of #2 and continue with PR #3.
(b) Close #2, abandon PR #3, and use this issue as the canonical spec (if this is a rewrite with better scoping). If so, the Lineage section must reference #2/#3 and explain why the rewrite was needed.
(c) If this issue covers something #2 does NOT (e.g., different acceptance criteria, different config approach), clarify the delta explicitly in the Context section.

2. Related section is underspecified.

The Related section references dora-metrics (a project slug) and docs/tiering.md (a file path), but does not reference issue #2 or PR #3 in this same repo. Any issue that overlaps with existing open work must cross-reference it.

NITS

Test Expectations could be more specific. The template guidance suggests naming specific spec files (e.g., tests/test_tiers.py). The current test expectations describe what to test but not where. PR #3 already created tests/test_tiers.py -- if this issue supersedes #2, the test file target should be explicit.
Acceptance Criteria item 3 references docs/tiering.md "in the DORA repo" -- which repo is that? Is it ldraney/DORA or ldraney/pal-e-dora-exporter? The reference should be a full org/repo path.
Lineage says "Migrated from ldraney/DORA#1" then "Standalone" on the next line. These are contradictory -- it is either a migration or standalone. Pick one.

VERDICT: NEEDS_REWORK

Items to fix before moving to next_up:

Resolve the duplicate scope with issue #2 and PR #3 (BLOCKER).
Add cross-references to #2 and #3 in Lineage and/or Related sections.
Clarify the docs/tiering.md repo reference in acceptance criteria.
Resolve the Lineage contradiction (migrated vs. standalone).
(Nit) Add specific test file paths to Test Expectations.

## Issue #5 Template Review ### TEMPLATE CONFORMANCE Template: `template-issue-feature` (pal-e-docs) - [x] `### Type` -- present, value "Feature" is valid - [x] `### Lineage` -- present, references `ldraney/DORA#1` migration - [x] `### Repo` -- present, correct repo `ldraney/pal-e-dora-exporter` - [x] `### User Story` -- present, follows As/I want/So that format - [x] `### Context` -- present, explains the motivation clearly - [x] `### File Targets` -- present, lists both modify and do-not-touch files - [x] `### Feature Flag` -- present, marked "None required" with rationale - [x] `### Acceptance Criteria` -- present, uses checkbox format - [x] `### Test Expectations` -- present, uses checkbox format - [x] `### Constraints` -- present, non-empty - [x] `### Checklist` -- present, uses checkbox format - [x] `### Related` -- present, references project and doc All 12 required sections present and non-empty. ### CONTENT QUALITY **File Targets -- GOOD.** All three paths verified against the repo tree on `main`: - `src/config.py` -- exists (786 bytes) - `src/collectors/forgejo.py` -- exists (5842 bytes) - `src/collectors/woodpecker.py` -- exists (4397 bytes) Negative targets (`Dockerfile`, `.woodpecker.yaml`) also verified as existing files correctly excluded. **User Story -- GOOD.** Clear, actionable, states the persona and value. **Context -- GOOD.** Self-contained explanation that doesn't require external knowledge. **Acceptance Criteria -- GOOD.** Testable, uses checkboxes. References `docs/tiering.md` for tier definitions. **Feature Flag -- GOOD.** "None required" is correct -- adding a label is additive and non-breaking. ### BLOCKERS **1. DUPLICATE SCOPE -- issue #2 and open PR #3 cover the same work.** Issue #2 ("Add tier label to all Prometheus metrics") was filed first and already has an open PR #3 implementing the exact same feature: adding a `tier` label to all metrics via a YAML config loader. PR #3 states "Closes #2". This issue (#5) targets the same three files, describes the same user story, and has overlapping acceptance criteria. There is no mention of #2 or #3 in the Lineage, Context, or Related sections. This is a scope collision. **Resolution required -- one of:** - (a) Close this issue as duplicate of #2 and continue with PR #3. - (b) Close #2, abandon PR #3, and use this issue as the canonical spec (if this is a rewrite with better scoping). If so, the Lineage section must reference #2/#3 and explain why the rewrite was needed. - (c) If this issue covers something #2 does NOT (e.g., different acceptance criteria, different config approach), clarify the delta explicitly in the Context section. **2. Related section is underspecified.** The Related section references `dora-metrics` (a project slug) and `docs/tiering.md` (a file path), but does not reference issue #2 or PR #3 in this same repo. Any issue that overlaps with existing open work must cross-reference it. ### NITS 1. **Test Expectations could be more specific.** The template guidance suggests naming specific spec files (e.g., `tests/test_tiers.py`). The current test expectations describe what to test but not where. PR #3 already created `tests/test_tiers.py` -- if this issue supersedes #2, the test file target should be explicit. 2. **Acceptance Criteria item 3** references `docs/tiering.md` "in the DORA repo" -- which repo is that? Is it `ldraney/DORA` or `ldraney/pal-e-dora-exporter`? The reference should be a full `org/repo` path. 3. **Lineage** says "Migrated from ldraney/DORA#1" then "Standalone" on the next line. These are contradictory -- it is either a migration or standalone. Pick one. ### VERDICT: NEEDS_REWORK **Items to fix before moving to next_up:** 1. Resolve the duplicate scope with issue #2 and PR #3 (BLOCKER). 2. Add cross-references to #2 and #3 in Lineage and/or Related sections. 3. Clarify the `docs/tiering.md` repo reference in acceptance criteria. 4. Resolve the Lineage contradiction (migrated vs. standalone). 5. (Nit) Add specific test file paths to Test Expectations.

ldraney commented

2026-06-13 19:19:56 +00:00

Author

Owner

Closing as duplicate of #2, which has open PR #3. Migrated from ldraney/DORA#1 during board migration but the work was already tracked here.