pal-e-docs

Review: Activate Woodpecker pipeline for notion-mcp-remote

review-1048-2026-04-21 Review

review approved
Project

Verdict: APPROVED

Scope is solid. Feature template fully satisfied, traceability triangle complete (minus the non-blocking arch-woodpecker note — same gap flagged in review-273 and review-882 and treated as non-blocking per precedent). Dependency on issue #5 (Harbor URL fix) is explicitly captured. File-target absence is correct for this ticket type — it is a Woodpecker-admin ticket, not a code change.
One notable field-state observation: the repo already reports active: true in Woodpecker (id 16). AC1 may already be satisfied mechanically. The implementing agent must verify activation is functional (webhook actually fires on a test commit) rather than just read the flag — see advisory below.

Template Completeness

  • [x] Type — Feature
  • [x] Lineage — standalone, scoped from project-notion-mcp-remote, cites service-onboarding-sop steps 7–8
  • [x] Repo — forgejo_admin/notion-mcp-remote
  • [x] User Story — operator wants activation + Harbor credentials so main push triggers build-and-push
  • [x] Context — explains why activation is manual (woodpecker-sdk #6 gap), why MCP tool is required for secrets
  • [x] File Targets — explicitly "No repo file changes. Woodpecker UI + MCP tool calls only." Correct for this ticket type.
  • [x] Acceptance Criteria — 5 concrete, machine-verifiable conditions
  • [x] Test Expectations — mcp__woodpecker__list_pipelines and build step log inspection
  • [x] Constraints — waits on tofu apply, requires MCP not UI
  • [x] Checklist — 6 steps covering prereqs and verification
  • [x] Related — project, story, SOP

Traceability

  • [x] story:ops-deploy-gitops label — matches story-notion-mcp-remote-ops-deploy-gitops
  • [x] story note verified — listed in project-notion-mcp-remote user-stories table
  • [x] arch:woodpecker label — identifies the Woodpecker CI component
  • [ ] arch note MISSING — arch-woodpecker search returned zero results. Non-blocking per precedent (review-273, review-882 flagged the same gap as non-blocking). See [SCOPE] recommendation below.
  • [x] Forgejo issue — forgejo_admin/notion-mcp-remote#8, state: open

File Targets

Issue states: "No repo file changes. Woodpecker UI + MCP tool calls only." This is correct — activation and secret provisioning are out-of-band platform operations, not repo edits. No file-target verification needed. Skipped per skill-review-ticket guidance for tickets with no file targets (Task-style scope inside a Feature wrapper).

Repo Placement

Issue is filed on forgejo_admin/notion-mcp-remote, the repo being activated. Correct placement. No cross-repo file changes required. The prerequisite Harbor robot lives in pal-e-platform (tracked separately in pal-e-platform#296 / pal-e-services#57) — the issue correctly treats those as upstream dependencies rather than pulling them into scope.

Dependencies

  • Hard prereq: Issue #5 (Harbor URL fix) must merge before AC5 can pass. Acknowledged in the Checklist. AC4 is satisfiable without it — a feature-branch push will reach the build-and-push step and fail at registry URL, which still proves activation + secrets are wired.
  • Soft prereq: tofu apply on pal-e-platform must produce the Harbor robot credentials before AC3 (values match robot, not admin). Tracked in board items #1045 (pal-e-platform#296) and #1043 (pal-e-services#57). Acknowledged in Constraints and Checklist.
  • Board state: All three dependencies (#5, pal-e-platform#296, pal-e-services#57) are in backlog. None in in_progress. Ordering is captured correctly in the ticket Checklist but no item is yet blocking this one on the board layer — the implementer must respect the Checklist ordering.

Acceptance Criteria

All 5 AC are concrete and machine-verifiable:
  • AC1 "Repo visible as active in Woodpecker UI" — verifiable via mcp__woodpecker__get_repo (active: true).
  • AC2 "Secrets harbor_username and harbor_password visible" — verifiable via mcp__woodpecker__list_repo_secrets.
  • AC3 "Values match Harbor robot (not admin)" — verifiable by cross-referencing Harbor robot account from tofu output.
  • AC4 "Feature branch push triggers pipeline that reaches build-and-push step" — verifiable via mcp__woodpecker__list_pipelines. Proves activation + secrets without needing the Harbor URL fix to be in place.
  • AC5 "Main push produces full green pipeline once Harbor URL fix lands" — gated on #5 merging; explicitly deferred.
AC4 is the critical validation step — it decouples activation verification from the Harbor URL fix dependency. Well-designed.

Blast Radius

Low. Pattern used by 7+ onboarded services (basketball-api, forgejo-mcp, gcal-mcp, gmail-mcp, pal-e-api, notion-mcp, westside-app, etc. — all visible as active: true in Woodpecker). No novel work. Failure mode is limited to this one repo: a bad secret prevents pipeline from pushing, which is non-destructive and trivially reversible via mcp__woodpecker__update_repo_secret.
Sibling-service scan: no other MCP-remote services in this fleet are missing activation. No pattern to spread.

Decomposition Assessment

File targets: 0 (platform ops only). AC count: 5 (within limit). Estimated agent time: 2–5 minutes (one activation check, two create_repo_secret calls, one test-commit push, one pipeline-list check). No subtask independence — linear sequential work.
No decomposition needed.

Field-State Observations (for the implementer)

  • Repo already reports active: true in Woodpecker (id 16). This means the activation button was already pressed at some point. However, list_pipelines for this repo returns [] — no run has ever executed. Possible causes: (a) no push has occurred since activation (recent activation), (b) webhook is misconfigured and never fires (see todo-woodpecker-webhook-token-fix — a known class of failure post-Postgres migration). The implementer MUST verify activation is functional by pushing a test commit and confirming a pipeline row appears, not just trust the active flag.
  • list_repo_secrets returns [] — harbor_username and harbor_password are genuinely missing. AC2 is real, outstanding work.
  • Dockerfile.k8s exists (referenced by .woodpecker.yaml:25). Pipeline config is ready to run; the only block is secrets + the Harbor URL fix.
  • .woodpecker.yaml is at .woodpecker.yaml (not .woodpecker.yml) — confirmed present on main at commit 837e2f2.

Recommendation

APPROVED. Ready to advance from backlog to todo, with the understanding that the implementer respects the Checklist ordering (Harbor robot from tofu must exist before AC3 can pass).
Advisory (non-blocking):
  • [SCOPE] Create architecture note arch-woodpecker in pal-e-docs. This is a cross-project gap surfaced by multiple recent reviews (review-273, review-882) and not unique to this ticket. Owner is the pal-e-platform project, not this one. Do not block this ticket on it.
  • [BODY] AC1 is mechanically already satisfied (active: true in Woodpecker). Suggest tightening AC1 to "Repo is active in Woodpecker and a test push produces a visible pipeline row in mcp__woodpecker__list_pipelines" so the implementer does not claim completion on a stale flag. Non-blocking — AC4 already covers the functional check, so an alert implementer will catch this anyway.