pal-e-docs

Review: Onboard westside-contracts to Woodpecker CI pipeline

review-578-2026-03-29 Review

review approved
Project

Verdict: APPROVED

Scope is solid. Well-structured feature issue with full template compliance, complete traceability triangle, and a proven reference implementation (westside-app). Minor file target inaccuracy and an undocumented cross-repo dependency are noted but do not block.

Template Completeness

  • [x] Type -- Feature
  • [x] Lineage -- discovered scope from pal-e-platform #206
  • [x] Repo -- forgejo_admin/westside-contracts
  • [x] User Story -- clear "platform operator wants CI pipeline for automated GitOps"
  • [x] Context -- explains kustomize-tag rollout blocker, adapter-node SvelteKit with direct Postgres
  • [x] File Targets -- .woodpecker.yaml listed
  • [x] Acceptance Criteria -- 5 testable conditions
  • [x] Test Expectations -- push change, verify pipeline, check kustomize overlay, ArgoCD sync
  • [x] Constraints -- follow existing patterns, use canonical script
  • [x] Checklist -- 6 discrete steps
  • [x] Related -- parent #206, reusable script PR #205, reference impl westside-app#124
All required sections present. Full template compliance for Feature type.

Traceability

  • [x] story:superuser-deploy -- present on board item #578
  • [x] arch:ci-pipeline -- present on board item #578
  • [x] Forgejo issue -- forgejo_admin/westside-contracts#30, state: open
All three legs of the traceability triangle are satisfied.

File Targets

  • [x] .woodpecker.yaml -- verified: file already exists at /home/ldraney/westside-contracts/.woodpecker.yaml (46 lines) with build + push steps. Issue says "(new)" but this is a modification to append the update-kustomize-tag step. Minor inaccuracy, agent will discover the existing file on read.
Advisory: The kustomize overlay files in pal-e-deployments are not listed as file targets. The agent will need to create overlays/westside-contracts/prod/kustomization.yaml in pal-e-deployments. The reference template (scripts/woodpecker-update-tag-step.yaml line 16) explicitly documents: westside-contracts -> (no overlay yet -- create one first). Agent will discover this from the reference implementation.

Repo Placement

Issue is filed on forgejo_admin/westside-contracts. Primary work is in that repo (.woodpecker.yaml modification). Secondary work touches forgejo_admin/pal-e-deployments (kustomize overlay creation). This cross-repo pattern is identical to every other onboarded service (westside-app, basketball-api, pal-e-docs, etc.). Single issue is acceptable since the overlay is a mechanical prerequisite, not independent scope.

Dependencies

  • [x] pal-e-platform#205 (reusable kustomize tag update script) -- CLOSED/satisfied. Script exists at scripts/update-kustomize-tag.sh.
  • [x] pal-e-platform#206 (rollout tracking issue) -- OPEN. This ticket is a child task. Not a blocker; #206 is the parent umbrella.
  • [x] Harbor project westside-contracts/app -- satisfied. Existing .woodpecker.yaml already pushes to this registry path.
  • [x] Board item #311 ("Activate westside-contracts in Woodpecker CI") -- marked DONE on board, but Woodpecker API returns 404 for this repo. Repo is not currently activated. AC #1 remains valid work; prior activation may have been lost.
No unresolved blocking dependencies.

Acceptance Criteria

5 acceptance criteria. All are verifiable by an agent:
  • [x] "Repo activated in Woodpecker CI" -- verifiable via mcp__woodpecker__get_repo
  • [x] ".woodpecker.yaml with build + push + update-kustomize-tag steps" -- verifiable by reading the file
  • [x] "forgejo_token secret provisioned" -- verifiable via mcp__woodpecker__list_repo_secrets
  • [x] "Harbor registry credentials provisioned" -- verifiable via Woodpecker secrets API (may already exist as global secrets)
  • [x] "One successful pipeline run" -- verifiable via mcp__woodpecker__list_pipelines
Test expectations are concrete and actionable. All criteria are specific and machine-verifiable.

Blast Radius

Low risk. This follows an established pattern used by 7+ onboarded services. The update-kustomize-tag.sh script is the canonical shared implementation. No novel patterns introduced. Change is additive (appending a pipeline step to an existing file + creating a standard overlay directory). Rollback is straightforward: remove the step from .woodpecker.yaml.

Decomposition Assessment

Apply the three-thing limit and five-minute rule:
  • File targets: 1 modification (.woodpecker.yaml) + 1 new file (kustomize overlay) = 2 files across 2 repos
  • Acceptance criteria: 5 (at the limit but acceptable -- 3 are Woodpecker admin actions, 1 is a file change, 1 is verification)
  • Estimated agent time: 3-4 minutes. All steps are mechanical and follow the westside-app reference implementation exactly.
  • Independent subtasks: None. Steps are sequential (activate -> add secrets -> modify pipeline -> push -> verify).
No decomposition needed.

Recommendation

No action needed. Ticket is approved for advancement.
Advisory notes (non-blocking, agent will self-discover):
  • [BODY] File target says "(new)" but .woodpecker.yaml already exists -- should say "(modify: add update-kustomize-tag step)". Agent will discover this on file read.
  • [BODY] Missing file target: pal-e-deployments/overlays/westside-contracts/prod/kustomization.yaml (new). Agent will need to create this for the tag update step to have a target. The reference template explicitly documents this gap.