Wire -health data into -summary instead of discarding it #8

New Issue

2026-08-01T17:40:44+03:00

oleks commented

2026-08-01 17:40:44 +03:00

Real-world usage feedback after the v0.2/v0.3 grind (2026-08-01): running
pipetree -health -summary against ~/projects does the full ~43s of
Woodpecker API round-trips (one per project, per annotateHealth), but
render.Summary never looks at Pipeline.Health at all — the fetched
data is silently discarded, and the user pays the latency for nothing.

Fix: when -health is combined with -summary, add a health rollup to
the summary output — at minimum counts of failing and stale pipelines
(e.g. "N pipeline(s) failing", "N pipeline(s) with no run in the last
-health-lookback window" vs "N healthy"). annotateHealth already runs
before the summary/analyze/tree branch in main.go, so this is purely a
render.Summary change (accept the already-annotated projects it's
given today, just read pl.Health too) — no new API calls needed.

Acceptance criteria

pipetree -health -summary prints health counts (failing/stale/
healthy, or similar) instead of silently ignoring the fetched data
pipetree -summary alone (no -health) is unchanged - the rollup
only appears when health data was actually fetched
documented in README/SPEC.md
verified against a real repo with at least one known-failing
pipeline (e.g. oleks/builder-arbitrage's test workflow, caught
failing live during the review that filed this issue)

Real-world usage feedback after the v0.2/v0.3 grind (2026-08-01): running `pipetree -health -summary` against `~/projects` does the full ~43s of Woodpecker API round-trips (one per project, per `annotateHealth`), but `render.Summary` never looks at `Pipeline.Health` at all — the fetched data is silently discarded, and the user pays the latency for nothing. Fix: when `-health` is combined with `-summary`, add a health rollup to the summary output — at minimum counts of failing and stale pipelines (e.g. "N pipeline(s) failing", "N pipeline(s) with no run in the last `-health-lookback` window" vs "N healthy"). `annotateHealth` already runs before the summary/analyze/tree branch in `main.go`, so this is purely a `render.Summary` change (accept the already-annotated `projects` it's given today, just read `pl.Health` too) — no new API calls needed. ## Acceptance criteria - [ ] `pipetree -health -summary` prints health counts (failing/stale/ healthy, or similar) instead of silently ignoring the fetched data - [ ] `pipetree -summary` alone (no `-health`) is unchanged - the rollup only appears when health data was actually fetched - [ ] documented in README/SPEC.md - [ ] verified against a real repo with at least one known-failing pipeline (e.g. `oleks/builder-arbitrage`'s `test` workflow, caught failing live during the review that filed this issue)

oleks added this to the v0.4 — Lint integration & MCP milestone 2026-08-01 17:40:44 +03:00

oleks added the enhancement label 2026-08-01 17:40:44 +03:00

oleks referenced this issue from a commit

2026-08-01 17:47:48 +03:00

Wire -health into -summary, distinguish not-registered from real API errors

oleks closed this issue

2026-08-01 17:47:48 +03:00

oleks commented

2026-08-01 17:50:15 +03:00

Resolved by 0ac15b7. Verified live: -health -summary against builder-arbitrage prints "6 pipeline(s) with a recent run (5 healthy, 1 failing, 0 other), 5 with no recent run found" — matching the live test-pipeline failure the feedback caught by hand.

Resolved by 0ac15b7. Verified live: -health -summary against builder-arbitrage prints "6 pipeline(s) with a recent run (5 healthy, 1 failing, 0 other), 5 with no recent run found" — matching the live test-pipeline failure the feedback caught by hand.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: oleks/pipetree#8