ldraney/landscaping-assistant
1
0
Fork 0
Code Issues 32 Pull requests 1 Projects Releases Packages Wiki Activity Actions 4

Woodpecker pipeline missing timestamps for DORA metrics #57

New issue
Open
opened 2026-06-02 12:44:09 +00:00 by ldraney · 1 comment
ldraney commented 2026-06-02 12:44:09 +00:00
Owner
Copy link

Type

Feature

Lineage

Standalone — discovered while monitoring pipeline #128. Related to observability chain (#43).

Repo

ldraney/landscaping-assistant

User Story

As a developer
I want pipeline start/finish timestamps exposed via the Woodpecker API
So that I can calculate DORA deployment frequency and lead time metrics

Context

While monitoring pipeline #128 (PR #56 merge to main), noticed started_at and finished_at are null in the Woodpecker API response for all pipelines — both current and historical. This blocks DORA metric calculation (deployment frequency, lead time for changes). Need to investigate whether this is a Woodpecker config issue, API version issue, or missing feature.

File Targets

Files the agent should modify or create:

  • .woodpecker.yml -- check if timestamp reporting needs config
  • Woodpecker server config -- check API version / timestamp support

Files the agent should NOT touch:

  • Application code -- this is infra-only

Acceptance Criteria

  • started_at and finished_at populated in Woodpecker API responses
  • Can calculate pipeline duration from API data
  • DORA deployment frequency derivable from push-to-main pipeline history

Test Expectations

  • Query list_pipelines and verify timestamps are non-null
  • Query get_pipeline_status and verify step-level timing

Constraints

  • May require Woodpecker server upgrade or config change
  • Check Woodpecker docs for timestamp support by version

Checklist

  • Root cause identified
  • Fix applied
  • Timestamps verified

Related

  • landscaping-assistant -- project
  • Parent: #43 (observability chain)
### Type Feature ### Lineage Standalone — discovered while monitoring pipeline #128. Related to observability chain (#43). ### Repo `ldraney/landscaping-assistant` ### User Story As a developer I want pipeline start/finish timestamps exposed via the Woodpecker API So that I can calculate DORA deployment frequency and lead time metrics ### Context While monitoring pipeline #128 (PR #56 merge to main), noticed `started_at` and `finished_at` are null in the Woodpecker API response for all pipelines — both current and historical. This blocks DORA metric calculation (deployment frequency, lead time for changes). Need to investigate whether this is a Woodpecker config issue, API version issue, or missing feature. ### File Targets Files the agent should modify or create: - `.woodpecker.yml` -- check if timestamp reporting needs config - Woodpecker server config -- check API version / timestamp support Files the agent should NOT touch: - Application code -- this is infra-only ### Acceptance Criteria - [ ] `started_at` and `finished_at` populated in Woodpecker API responses - [ ] Can calculate pipeline duration from API data - [ ] DORA deployment frequency derivable from push-to-main pipeline history ### Test Expectations - [ ] Query `list_pipelines` and verify timestamps are non-null - [ ] Query `get_pipeline_status` and verify step-level timing ### Constraints - May require Woodpecker server upgrade or config change - Check Woodpecker docs for timestamp support by version ### Checklist - [ ] Root cause identified - [ ] Fix applied - [ ] Timestamps verified ### Related - `landscaping-assistant` -- project - Parent: #43 (observability chain)
ldraney commented 2026-06-02 20:52:43 +00:00
Author
Owner
Copy link

Ticket Scope Review -- Board Item 1296

INVESTIGATION SUMMARY

I verified the problem statement by querying the Woodpecker API directly:

  • list_pipelines for ldraney/landscaping-assistant -- all three most recent pipelines (132, 133, 135) return created_at: null
  • get_pipeline_status for pipeline 135 -- created_at, started_at, and finished_at are all null, even though steps show meaningful statuses (success, running, pending)
  • Woodpecker server version is 3.13.0

The null timestamps are confirmed and real. This blocks DORA metric calculation (deployment frequency, lead time) as described.

FILE TARGETS -- PROBLEM

The issue says to modify:

  1. .woodpecker.yml
  2. Woodpecker server configuration

Neither of these is correct for this problem.

  • .woodpecker.yml defines pipeline steps, triggers, and services. It has no control over API response timestamp fields. The current .woodpecker.yaml (note: actual filename uses .yaml extension, not .yml as stated) is a standard pipeline definition with clone, lint, test, and build-and-push steps. Nothing in this file can influence whether the API returns timestamps.

  • Woodpecker server configuration does not live in this repo. There is no k8s/, helm/, deploy/, or infrastructure/ directory. The Woodpecker server is managed at the platform level, not per-repo.

Root cause is likely one of:

  1. The MCP tool (mcp__woodpecker__list_pipelines / get_pipeline_status) is not mapping the timestamp fields from the Woodpecker API response correctly (serialization bug in the MCP adapter)
  2. A Woodpecker 3.x API schema change where timestamp field names differ from what the MCP tool expects (e.g., created vs created_at, or Unix epoch vs ISO 8601)
  3. An actual Woodpecker server bug (less likely given 3.13.0 is recent)

The fix almost certainly lives in the Woodpecker MCP tool source code, not in this repo.

ACCEPTANCE CRITERIA REVIEW

  • "Populate started_at and finished_at in API responses" -- This is testable via the MCP tools, good.
  • "Enable pipeline duration calculation" -- Derived from the above, fine.
  • "Support DORA metric derivation from deployment history" -- Vague. What specific DORA metrics? Deployment frequency needs created_at on successful main-branch pushes. Lead time needs PR merge timestamps (from Forgejo, not Woodpecker). This criterion needs tightening.

DEPENDENCY CHECK

  • Parent issue #43 (Observability & DORA stack) is tracked, good.
  • Issue #20 (DORA metrics in Grafana) depends on this being resolved, creating a proper dependency chain.
  • No missing dependencies identified.

SCOPE CONCERNS

  1. Wrong repo: The fix is almost certainly in the Woodpecker MCP tool, not in landscaping-assistant. An agent picking up this ticket in this repo will have no files to change.
  2. Wrong file targets: .woodpecker.yml modification will not fix null API timestamps. The file target should reference the MCP tool source.
  3. Filename mismatch: The issue references .woodpecker.yml but the actual file is .woodpecker.yaml.
  4. Investigation vs. implementation: The issue correctly identifies this needs investigation first, but then lists concrete file targets as if the fix location is known. These contradict each other.

VERDICT: REQUEST_CHANGES

Reasons to stay in backlog:

  1. Wrong repo scope: This ticket cannot be executed by an agent working in landscaping-assistant. The null timestamps come from the Woodpecker API/MCP layer, not from the pipeline definition. The ticket should either (a) be moved to the Woodpecker MCP tool repo, or (b) be reframed as a pure investigation ticket that identifies the root cause and files a follow-up in the correct repo.

  2. File targets are incorrect: .woodpecker.yml (which is actually .woodpecker.yaml) has no bearing on API response timestamps. An agent would waste cycles modifying a file that cannot fix the problem.

  3. Acceptance criteria need the "where": "Populate started_at and finished_at" is the right goal, but without identifying which codebase to modify, an agent cannot execute this.

Suggested rework:

  • Reframe as investigation-only: "Determine whether null timestamps originate from Woodpecker server, Woodpecker API version incompatibility, or MCP tool serialization"
  • Remove .woodpecker.yml from file targets
  • Add a concrete next step: "If MCP tool bug, file issue in MCP tool repo; if server config, file issue in platform-infra repo"
  • Fix filename reference to .woodpecker.yaml
## Ticket Scope Review -- Board Item 1296 ### INVESTIGATION SUMMARY I verified the problem statement by querying the Woodpecker API directly: - `list_pipelines` for `ldraney/landscaping-assistant` -- all three most recent pipelines (132, 133, 135) return `created_at: null` - `get_pipeline_status` for pipeline 135 -- `created_at`, `started_at`, and `finished_at` are all null, even though steps show meaningful statuses (success, running, pending) - Woodpecker server version is **3.13.0** The null timestamps are confirmed and real. This blocks DORA metric calculation (deployment frequency, lead time) as described. ### FILE TARGETS -- PROBLEM The issue says to modify: 1. `.woodpecker.yml` 2. Woodpecker server configuration **Neither of these is correct for this problem.** - `.woodpecker.yml` defines pipeline steps, triggers, and services. It has no control over API response timestamp fields. The current `.woodpecker.yaml` (note: actual filename uses `.yaml` extension, not `.yml` as stated) is a standard pipeline definition with clone, lint, test, and build-and-push steps. Nothing in this file can influence whether the API returns timestamps. - Woodpecker server configuration does not live in this repo. There is no `k8s/`, `helm/`, `deploy/`, or `infrastructure/` directory. The Woodpecker server is managed at the platform level, not per-repo. **Root cause is likely one of:** 1. The MCP tool (`mcp__woodpecker__list_pipelines` / `get_pipeline_status`) is not mapping the timestamp fields from the Woodpecker API response correctly (serialization bug in the MCP adapter) 2. A Woodpecker 3.x API schema change where timestamp field names differ from what the MCP tool expects (e.g., `created` vs `created_at`, or Unix epoch vs ISO 8601) 3. An actual Woodpecker server bug (less likely given 3.13.0 is recent) The fix almost certainly lives in the **Woodpecker MCP tool source code**, not in this repo. ### ACCEPTANCE CRITERIA REVIEW - "Populate `started_at` and `finished_at` in API responses" -- This is testable via the MCP tools, good. - "Enable pipeline duration calculation" -- Derived from the above, fine. - "Support DORA metric derivation from deployment history" -- Vague. What specific DORA metrics? Deployment frequency needs `created_at` on successful main-branch pushes. Lead time needs PR merge timestamps (from Forgejo, not Woodpecker). This criterion needs tightening. ### DEPENDENCY CHECK - Parent issue #43 (Observability & DORA stack) is tracked, good. - Issue #20 (DORA metrics in Grafana) depends on this being resolved, creating a proper dependency chain. - No missing dependencies identified. ### SCOPE CONCERNS 1. **Wrong repo**: The fix is almost certainly in the Woodpecker MCP tool, not in `landscaping-assistant`. An agent picking up this ticket in this repo will have no files to change. 2. **Wrong file targets**: `.woodpecker.yml` modification will not fix null API timestamps. The file target should reference the MCP tool source. 3. **Filename mismatch**: The issue references `.woodpecker.yml` but the actual file is `.woodpecker.yaml`. 4. **Investigation vs. implementation**: The issue correctly identifies this needs investigation first, but then lists concrete file targets as if the fix location is known. These contradict each other. ### VERDICT: REQUEST_CHANGES **Reasons to stay in backlog:** 1. **Wrong repo scope**: This ticket cannot be executed by an agent working in `landscaping-assistant`. The null timestamps come from the Woodpecker API/MCP layer, not from the pipeline definition. The ticket should either (a) be moved to the Woodpecker MCP tool repo, or (b) be reframed as a pure investigation ticket that identifies the root cause and files a follow-up in the correct repo. 2. **File targets are incorrect**: `.woodpecker.yml` (which is actually `.woodpecker.yaml`) has no bearing on API response timestamps. An agent would waste cycles modifying a file that cannot fix the problem. 3. **Acceptance criteria need the "where"**: "Populate started_at and finished_at" is the right goal, but without identifying which codebase to modify, an agent cannot execute this. **Suggested rework:** - Reframe as investigation-only: "Determine whether null timestamps originate from Woodpecker server, Woodpecker API version incompatibility, or MCP tool serialization" - Remove `.woodpecker.yml` from file targets - Add a concrete next step: "If MCP tool bug, file issue in MCP tool repo; if server config, file issue in platform-infra repo" - Fix filename reference to `.woodpecker.yaml`
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
docs/update-app-architecture
revert-213
move-other-crew-bottom-remove-schedule
feature/today-view-improvements
154-enable-assume-ssl
revert-145-person-icon
docs/user-stories-auth
docs/update-infra-pipeline-post-incident
fix-cache-step-blocking-deploy
fix-kaniko-registry-pull
deactivate-from-today
feature/quick-address-entry
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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/landscaping-assistant#57
No description provided.