-health is structurally blind on fork-workflow repos: resolves the Woodpecker repo from origin, not the upstream that actually builds #10

New Issue

2026-08-02T22:18:34+03:00

oleks commented

2026-08-02 22:18:34 +03:00

pipetree -health derives the Woodpecker repo slug from the local origin remote. In a fork workflow — work branches on a fork, CI and the branch ladder on the upstream — origin points at the fork, which has no pipelines, so every pipeline reports "no recent run found" even while CI is actively running.

Observed 2026-08-02 against ~/projects/forrest:

$ pipetree -C ~/projects/forrest -health -summary
2 project(s) scanned (1 with no pipeline file)
14 pipeline(s), 49 step(s)
health: 0 pipeline(s) with a recent run (0 healthy, 0 failing, 0 other), 14 with no recent run found

That is wrong — CI had run minutes earlier. The cause:

$ pipetree -C ~/projects/forrest -health -json | jq -r '.[] | {name, remote}'
{ "name": "forrest", "remote": "oleks/forrest" }

$ git -C ~/projects/forrest remote -v
origin  https://git.oleks.space/oleks/forrest.git (fetch)
origin  https://git.oleks.space/oleks/forrest.git (push)

But the pipelines live on the upstream:

$ curl -s -H "Authorization: Bearer $WOODPECKER_TOKEN" "$WOODPECKER_SERVER/api/repos/lookup/anton/forrest"
id=142 full_name=anton/forrest active=True

$ curl -s -H "Authorization: Bearer $WOODPECKER_TOKEN" "$WOODPECKER_SERVER/api/repos/142/pipelines?perPage=3"
#2826 success cron         agent-wip-claim-sweep
#2825 success push         Merge pull request 'fix(i18n): seed uk primary and footer nav menus…'
#2823 success pull_request fix(i18n): seed uk primary and footer nav menus…

Note lookup/oleks/forrest returns HTTP 200 as well (the fork is registered but never builds), so the failure is silent — it looks like a healthy scan of a repo that simply has no runs, rather than a lookup pointed at the wrong place.

Why it matters. The cicd-insights catalog rows that depend on -health — CI health, staleness, regression correlation — all silently return nothing for this class of repo, and "14 with no recent run found" reads as a real finding (stale/abandoned pipelines) rather than as a tool limitation. It is a false negative that looks like a true positive.

Suggested fix, roughly in order of preference:

Prefer an upstream remote over origin when both exist, since that is the conventional fork layout.
Add an explicit override flag (e.g. -remote anton/forrest) so the caller can pin it.
When a resolved repo is registered but has zero pipelines ever, say so distinctly ("registered, no pipelines — wrong repo?") instead of folding it into the generic "no recent run found" bucket, so the failure is at least visible.

Even (3) alone would have prevented the misread.

`pipetree -health` derives the Woodpecker repo slug from the local `origin` remote. In a fork workflow — work branches on a fork, CI and the branch ladder on the upstream — `origin` points at the fork, which has no pipelines, so every pipeline reports "no recent run found" even while CI is actively running. **Observed 2026-08-02** against `~/projects/forrest`: ``` $ pipetree -C ~/projects/forrest -health -summary 2 project(s) scanned (1 with no pipeline file) 14 pipeline(s), 49 step(s) health: 0 pipeline(s) with a recent run (0 healthy, 0 failing, 0 other), 14 with no recent run found ``` That is wrong — CI had run minutes earlier. The cause: ``` $ pipetree -C ~/projects/forrest -health -json | jq -r '.[] | {name, remote}' { "name": "forrest", "remote": "oleks/forrest" } $ git -C ~/projects/forrest remote -v origin https://git.oleks.space/oleks/forrest.git (fetch) origin https://git.oleks.space/oleks/forrest.git (push) ``` But the pipelines live on the upstream: ``` $ curl -s -H "Authorization: Bearer $WOODPECKER_TOKEN" "$WOODPECKER_SERVER/api/repos/lookup/anton/forrest" id=142 full_name=anton/forrest active=True $ curl -s -H "Authorization: Bearer $WOODPECKER_TOKEN" "$WOODPECKER_SERVER/api/repos/142/pipelines?perPage=3" #2826 success cron agent-wip-claim-sweep #2825 success push Merge pull request 'fix(i18n): seed uk primary and footer nav menus…' #2823 success pull_request fix(i18n): seed uk primary and footer nav menus… ``` Note `lookup/oleks/forrest` returns HTTP 200 as well (the fork is registered but never builds), so the failure is silent — it looks like a healthy scan of a repo that simply has no runs, rather than a lookup pointed at the wrong place. **Why it matters.** The `cicd-insights` catalog rows that depend on `-health` — CI health, staleness, regression correlation — all silently return nothing for this class of repo, and "14 with no recent run found" reads as a real finding (stale/abandoned pipelines) rather than as a tool limitation. It is a false negative that looks like a true positive. **Suggested fix**, roughly in order of preference: 1. Prefer an `upstream` remote over `origin` when both exist, since that is the conventional fork layout. 2. Add an explicit override flag (e.g. `-remote anton/forrest`) so the caller can pin it. 3. When a resolved repo is registered but has **zero** pipelines ever, say so distinctly ("registered, no pipelines — wrong repo?") instead of folding it into the generic "no recent run found" bucket, so the failure is at least visible. Even (3) alone would have prevented the misread.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: oleks/pipetree#10

-health is structurally blind on fork-workflow repos: resolves the Woodpecker repo from origin, not the upstream that actually builds #10

-health is structurally blind on fork-workflow repos: resolves the Woodpecker repo from `origin`, not the upstream that actually builds #10