Pipeline failure data for CFR/MTTR #4

Closed
opened 2026-06-13 18:35:54 +00:00 by ldraney · 1 comment
Owner

Type

Feature

Lineage

New issue — created as part of DORA measurement expansion (2026-06-13).

Repo

ldraney/woodpecker-mcp

User Story

As an AI agent
I want to query pipeline failure rates and recent failures per repo
So that I can calculate CFR and MTTR for DORA reporting

What

Add an MCP tool that returns pipeline failure rate and recent failures per repo, enabling CFR and MTTR calculation from the agent side.

Why

woodpecker-mcp exposes pipeline tools but does not surface failure correlation data in a DORA-friendly way. Agents need structured failure data to calculate CFR and MTTR without scraping raw pipeline lists.

Context

The existing pipeline tools return individual pipeline status but do not aggregate success/failure counts or provide time-windowed failure rates. A dedicated tool simplifies DORA metric calculation.

File Targets

  • src/woodpecker_mcp/tools/dora.py — new tool module for DORA query tools (or equivalent path)
  • src/woodpecker_mcp/server.py — register new tools
  • tests/test_dora_tools.py — tests for new tools

Feature Flag

None required — new MCP tool is additive.

Acceptance Criteria

  • New MCP tool returns pipeline success/failure counts for a given repo over a time range
  • Includes timestamps for recent failures
  • Enables CFR calculation (failures / total deployments)
  • Time range parameter with sensible defaults

Test Expectations

  • Unit test: tool returns correct counts for mock pipeline data
  • Unit test: time range filtering works correctly

Constraints

  • Follow existing woodpecker-mcp tool patterns and conventions
  • Must work with Woodpecker API

Checklist

  • PR opened
  • Tests pass
  • No unrelated changes
  • dora-metrics — project this affects
  • DORA framework measurement automation roadmap
### Type Feature ### Lineage New issue — created as part of DORA measurement expansion (2026-06-13). ### Repo `ldraney/woodpecker-mcp` ### User Story As an AI agent I want to query pipeline failure rates and recent failures per repo So that I can calculate CFR and MTTR for DORA reporting ### What Add an MCP tool that returns pipeline failure rate and recent failures per repo, enabling CFR and MTTR calculation from the agent side. ### Why woodpecker-mcp exposes pipeline tools but does not surface failure correlation data in a DORA-friendly way. Agents need structured failure data to calculate CFR and MTTR without scraping raw pipeline lists. ### Context The existing pipeline tools return individual pipeline status but do not aggregate success/failure counts or provide time-windowed failure rates. A dedicated tool simplifies DORA metric calculation. ### File Targets - `src/woodpecker_mcp/tools/dora.py` — new tool module for DORA query tools (or equivalent path) - `src/woodpecker_mcp/server.py` — register new tools - `tests/test_dora_tools.py` — tests for new tools ### Feature Flag None required — new MCP tool is additive. ### Acceptance Criteria - [ ] New MCP tool returns pipeline success/failure counts for a given repo over a time range - [ ] Includes timestamps for recent failures - [ ] Enables CFR calculation (failures / total deployments) - [ ] Time range parameter with sensible defaults ### Test Expectations - [ ] Unit test: tool returns correct counts for mock pipeline data - [ ] Unit test: time range filtering works correctly ### Constraints - Follow existing woodpecker-mcp tool patterns and conventions - Must work with Woodpecker API ### Checklist - [ ] PR opened - [ ] Tests pass - [ ] No unrelated changes ### Related - `dora-metrics` — project this affects - DORA framework measurement automation roadmap
Author
Owner

Issue #4 Template Review

TEMPLATE CONFORMANCE

  • ### Type present and valid (Feature)
  • ### Lineage present and non-empty
  • ### Repo present and correct (ldraney/woodpecker-mcp)
  • ### User Story present, follows As/I want/So that format
  • ### Context present and non-empty
  • ### File Targets present with specific paths
  • ### Feature Flag present ("None required" -- acceptable for additive MCP tool)
  • ### Acceptance Criteria present with checkboxes
  • ### Test Expectations present with checkboxes
  • ### Constraints present and non-empty
  • ### Checklist present with standard items
  • ### Related present

Extra sections ### What and ### Why are present -- not in the template but harmless. They duplicate information already in Context/User Story but don't cause confusion.

CONTENT QUALITY

File Targets -- validated against repo tree:

  • src/woodpecker_mcp/tools/dora.py (new) -- Follows the existing tools/{domain}.py pattern. Consistent with crons.py, pipelines.py, repos.py, etc.
  • src/woodpecker_mcp/server.py (modify) -- Exists. Correct touch point for registering new tools.
  • tests/test_dora_tools.py (new) -- Path works but breaks the repo naming convention. Existing tests are test_crons.py, test_pipelines.py, test_repos.py, etc. (no _tools suffix). Should be tests/test_dora.py for consistency.

Acceptance Criteria assessment:

  • Criteria are testable and specific. Time range parameter with defaults is good scope.
  • Missing: no mention of error handling (what if repo doesn't exist, or Woodpecker API is unreachable). Consider adding at least one error-path criterion.

Test Expectations assessment:

  • Two unit tests specified (counts + time range filtering). Adequate for the scope.
  • No integration test listed -- consistent with the rest of the repo (all test files are unit tests with mocks).

Scope assessment:

  • Single deployable unit: one new tool module, one server registration, one test file. Clean scope.
  • No splitting needed.

Dependencies:

  • Depends on Woodpecker API pipeline endpoints being available. The existing pipelines.py tool already calls these, so the dependency is already satisfied.
  • No downstream dependencies called out -- acceptable since this is additive.

BLOCKERS

None.

NITS

  1. Test file naming: tests/test_dora_tools.py should be tests/test_dora.py to match repo convention (test_{domain}.py without _tools suffix).
  2. Extra sections: ### What and ### Why duplicate ### User Story and ### Context. Not harmful but adds noise -- consider removing for template cleanliness.
  3. Error handling AC: Consider adding an acceptance criterion for error cases (invalid repo, API timeout).

VERDICT: APPROVED

## Issue #4 Template Review ### TEMPLATE CONFORMANCE - [x] `### Type` present and valid (Feature) - [x] `### Lineage` present and non-empty - [x] `### Repo` present and correct (`ldraney/woodpecker-mcp`) - [x] `### User Story` present, follows As/I want/So that format - [x] `### Context` present and non-empty - [x] `### File Targets` present with specific paths - [x] `### Feature Flag` present ("None required" -- acceptable for additive MCP tool) - [x] `### Acceptance Criteria` present with checkboxes - [x] `### Test Expectations` present with checkboxes - [x] `### Constraints` present and non-empty - [x] `### Checklist` present with standard items - [x] `### Related` present Extra sections `### What` and `### Why` are present -- not in the template but harmless. They duplicate information already in Context/User Story but don't cause confusion. ### CONTENT QUALITY **File Targets -- validated against repo tree:** - `src/woodpecker_mcp/tools/dora.py` (new) -- Follows the existing `tools/{domain}.py` pattern. Consistent with `crons.py`, `pipelines.py`, `repos.py`, etc. - `src/woodpecker_mcp/server.py` (modify) -- Exists. Correct touch point for registering new tools. - `tests/test_dora_tools.py` (new) -- Path works but breaks the repo naming convention. Existing tests are `test_crons.py`, `test_pipelines.py`, `test_repos.py`, etc. (no `_tools` suffix). Should be `tests/test_dora.py` for consistency. **Acceptance Criteria assessment:** - Criteria are testable and specific. Time range parameter with defaults is good scope. - Missing: no mention of error handling (what if repo doesn't exist, or Woodpecker API is unreachable). Consider adding at least one error-path criterion. **Test Expectations assessment:** - Two unit tests specified (counts + time range filtering). Adequate for the scope. - No integration test listed -- consistent with the rest of the repo (all test files are unit tests with mocks). **Scope assessment:** - Single deployable unit: one new tool module, one server registration, one test file. Clean scope. - No splitting needed. **Dependencies:** - Depends on Woodpecker API pipeline endpoints being available. The existing `pipelines.py` tool already calls these, so the dependency is already satisfied. - No downstream dependencies called out -- acceptable since this is additive. ### BLOCKERS None. ### NITS 1. **Test file naming:** `tests/test_dora_tools.py` should be `tests/test_dora.py` to match repo convention (`test_{domain}.py` without `_tools` suffix). 2. **Extra sections:** `### What` and `### Why` duplicate `### User Story` and `### Context`. Not harmful but adds noise -- consider removing for template cleanliness. 3. **Error handling AC:** Consider adding an acceptance criterion for error cases (invalid repo, API timeout). ### VERDICT: APPROVED
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ldraney/woodpecker-mcp#4
No description provided.