pal-e-docs

Validation: fix(ci): switch Woodpecker image push to internal Harbor URL

validation-5-2026-04-22 Doc

validation pass
Project

Verdict: PASS (by inspection)

Empirical push-to-Harbor verification is explicitly deferred to ticket board #1048 / forgejo_admin/notion-mcp-remote#8 (Activate Woodpecker), which gates pipeline execution for this repo. All in-scope inspection checks green.

Ticket

  • Forgejo issue: forgejo_admin/notion-mcp-remote#5 — fix(ci): switch Woodpecker image push to internal Harbor URL
  • Merged PR: forgejo_admin/notion-mcp-remote#10 (squash-merged as cb91a12)
  • Board item: #1042 on board-notion-mcp-remote, column validation
  • Labels: type:bug,story:ops-deploy-gitops,arch:woodpecker
  • One-liner: change .woodpecker.yaml kaniko registry: from the external Tailscale URL to the in-cluster Harbor service DNS.

Environment

  • Repo: forgejo_admin/notion-mcp-remote branch main at cb91a12
  • Config surface under test: .woodpecker.yaml (CI config, not a runtime pod)
  • Downstream registry (for context only): harbor-core.harbor.svc.cluster.local (in-cluster) — exercised once pipelines run on this repo
  • Woodpecker repo status: active: true, but list_pipelines shows only the PR/push events for this change; pipeline #2 (post-merge push) reported status: error, consistent with the unresolved activation work tracked on board #1048.

Tier Selection

This PR is a CI build-config change, not a pod deploy. The repo is labeled api-like, but Tier 3 prod-pod/endpoint checks are not applicable to this specific diff (no image was rebuilt, no pod rolled). The validation therefore reduces to Tier 1 inspection of the merged config on main plus boundary confirmation that nothing else shifted. Empirical CI validation (Tier 1b: actual push to Harbor) is explicitly scoped to #1048.

Checks

# Acceptance Criterion How Verified Result Evidence
1 Squash-merge landed on main with the <code>harbor-core.harbor.svc.cluster.local</code> registry value <code>git show origin/main:.woodpecker.yaml</code> PASS Line 22: <code>registry: harbor-core.harbor.svc.cluster.local</code>
2 Diff is exactly one line; no regressions in adjacent kaniko settings <code>git show cb91a12 -- .woodpecker.yaml</code> PASS <code>1 file changed, 1 insertion(+), 1 deletion(-)</code>. Only the <code>registry:</code> line changed; <code>repo</code>, <code>tags</code>, <code>dockerfile</code>, <code>build_args</code>, <code>username</code> (from_secret: harbor_username), <code>password</code> (from_secret: harbor_password) all unchanged.
3 YAML still parses <code>python3 -c "import yaml; yaml.safe_load(...)"</code> on the file from <code>origin/main</code> PASS <code>YAML PARSES OK</code>
4 <code>k8s/deployment.yaml</code> external URL intentionally untouched (per scope review — image pull is kubelet-side and external URL stays until image-pull path is redone) <code>grep -nE "harbor\|tail5b443a\|image:" k8s/deployment.yaml</code> on <code>origin/main</code> PASS Line 23: <code>image: harbor.tail5b443a.ts.net/notion-mcp-remote/notion-mcp-remote:latest</code> — unchanged, matches scope expectation.
5 Forgejo issue #5 closed <code>mcp__forgejo__list_issues(state=closed)</code> PASS Issue #5 appears in closed list, state=<code>closed</code>.
6 PR #10 merged <code>mcp__forgejo__list_prs(state=closed)</code> PASS PR #10, <code>merged: true</code>.
7 Empirical end-to-end: Woodpecker push-to-Harbor succeeds on <code>main</code> after merge Would require <code>list_pipelines</code> to show a green <code>build-and-push</code> step against <code>harbor-core.harbor.svc.cluster.local</code> DEFERRED Pipeline #2 (push event on main at <code>cb91a12</code>) reports <code>status: error</code>. Root cause is the Woodpecker activation / secrets / trust-flags work tracked on <strong>board #1048 / notion-mcp-remote#8</strong>, not a defect in this PR's diff. Empirical signal for this AC will be captured in that ticket's validation pass.

Regression Check

  • Pipeline parse: YAML still loads via yaml.safe_load; no structural damage.
  • Test step: unchanged. Pipeline #1 (PR #10) ran the test step to success, proving the file still schedules at least the pre-build steps.
  • Deployment manifest: k8s/deployment.yaml image reference unchanged; kubelet pull path not disturbed by this PR.
  • Secrets reference: from_secret: harbor_username and from_secret: harbor_password untouched; no secret rename required.

Discovered Issues

None introduced by PR #10. The post-merge pipeline error on main (pipeline #2, status: error) is a pre-existing condition already captured by board #1048 / forgejo_admin/notion-mcp-remote#8 — Activate Woodpecker (currently in todo). No new follow-up ticket needed.

Verdict Reasoning

PASS by inspection is the right call because:
  • The fix is correct by direct inspection of main — the registry value is now the in-cluster Harbor service DNS, which is what Woodpecker runners need.
  • The empirical step has a named ticket and owner (#1048 / notion-mcp-remote#8), so the chain is traceable and not lost.
  • Blocking #1042 in validation would create false pressure on the #1048 timeline without adding safety — the inspection-level checks are sufficient to confirm this PR did its job.
If #1048's validation pass later exposes a problem that traces back to the registry value set here, reopen #5 and revisit.
  • sop-validation — SOP this note follows
  • template-validation — template format
  • skill-validate-ticket — driving skill
  • Board #1048 / forgejo_admin/notion-mcp-remote#8 — Activate Woodpecker (owns the deferred empirical step)