Distinguish "repo not registered in Woodpecker" from a real -health API error #9

New Issue

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

oleks commented

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

Real-world usage feedback after the v0.2/v0.3 grind (2026-08-01):
-health errored on antigravity-plugin-registry with a bare "404" from
the Woodpecker repo-lookup endpoint (GET /api/repos/lookup/{owner}/ {name} in internal/health.Client.repoID). Almost certainly means the
repo simply isn't registered/enabled in Woodpecker (the same "not
registered" case cluster:ci-agent's woodpecker-gitea-bond skill
already handles - see how it activated oleks/pipetree itself earlier
this session via POST /api/repos?forge_remote_id=...), not a genuine API
problem (auth failure, server down, network issue) - but pipetree's
current error text doesn't say so, so a user has to already know Woodpecker
internals to tell the two apart.

Acceptance criteria

health.Client.repoID (or its caller) detects a 404 specifically
and returns/wraps a distinguishable "not registered in Woodpecker"
condition rather than a generic HTTP-status error
annotateHealth's stderr message for that case reads as
informational ("not registered in Woodpecker, skipping") rather
than as an error a user needs to debug
genuine API problems (401/403/5xx, network errors) still surface as
clear errors, distinct from the 404 case
verified against a real never-registered repo (e.g.
antigravity-plugin-registry, the case that surfaced this) and a
real registered one, to confirm both paths render correctly

Real-world usage feedback after the v0.2/v0.3 grind (2026-08-01): `-health` errored on `antigravity-plugin-registry` with a bare "404" from the Woodpecker repo-lookup endpoint (`GET /api/repos/lookup/{owner}/ {name}` in `internal/health.Client.repoID`). Almost certainly means the repo simply isn't registered/enabled in Woodpecker (the same "not registered" case `cluster:ci-agent`'s `woodpecker-gitea-bond` skill already handles - see how it activated `oleks/pipetree` itself earlier this session via `POST /api/repos?forge_remote_id=...`), not a genuine API problem (auth failure, server down, network issue) - but pipetree's current error text doesn't say so, so a user has to already know Woodpecker internals to tell the two apart. ## Acceptance criteria - [ ] `health.Client.repoID` (or its caller) detects a 404 specifically and returns/wraps a distinguishable "not registered in Woodpecker" condition rather than a generic HTTP-status error - [ ] `annotateHealth`'s stderr message for that case reads as informational ("not registered in Woodpecker, skipping") rather than as an error a user needs to debug - [ ] genuine API problems (401/403/5xx, network errors) still surface as clear errors, distinct from the 404 case - [ ] verified against a real never-registered repo (e.g. `antigravity-plugin-registry`, the case that surfaced this) and a real registered one, to confirm both paths render correctly

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

oleks added the enhancement label 2026-08-01 17:40:54 +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 against antigravity-plugin-registry now prints "not registered in Woodpecker, skipping" instead of a bare 404.

Resolved by 0ac15b7. Verified live: -health against antigravity-plugin-registry now prints "not registered in Woodpecker, skipping" instead of a bare 404.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: oleks/pipetree#9