feat: add update-kustomize-tag Woodpecker step #124

Merged
forgejo_admin merged 1 commit from 123-update-kustomize-tag into main 2026-03-27 21:11:51 +00:00

Summary

  • Adds the update-kustomize-tag step to the Woodpecker pipeline so that after a successful build-and-push on main, the image tag in pal-e-deployments/overlays/westsidekingsandqueens/prod is automatically bumped
  • This closes the CD loop -- ArgoCD detects the commit and rolls out the new image without manual intervention

Changes

  • .woodpecker.yaml: Added update-kustomize-tag step after build-and-push, using the canonical script from pal-e-platform/scripts/update-kustomize-tag.sh via internal service URL. Uses forgejo_token secret, OVERLAY=westsidekingsandqueens, triggers only on push to main.

Test Plan

  • forgejo_token secret exists in Woodpecker for this repo (confirmed: scoped to push events)
  • Merge to main and confirm the pipeline runs all three steps: validate, build-and-push, update-kustomize-tag
  • Verify a commit appears in pal-e-deployments updating the westsidekingsandqueens overlay tag
  • Verify ArgoCD picks up the new tag and syncs the deployment

Review Checklist

  • Passed automated review-fix loop
  • No secrets committed
  • No unnecessary file changes
  • Commit messages are descriptive
  • forgejo_admin/westside-app #123 -- the Forgejo issue this PR implements (Closes #123)
  • westside-app -- the project this work belongs to
  • Template: pal-e-platform/scripts/woodpecker-update-tag-step.yaml
  • Script: pal-e-platform/scripts/update-kustomize-tag.sh
## Summary - Adds the `update-kustomize-tag` step to the Woodpecker pipeline so that after a successful build-and-push on main, the image tag in `pal-e-deployments/overlays/westsidekingsandqueens/prod` is automatically bumped - This closes the CD loop -- ArgoCD detects the commit and rolls out the new image without manual intervention ## Changes - `.woodpecker.yaml`: Added `update-kustomize-tag` step after `build-and-push`, using the canonical script from `pal-e-platform/scripts/update-kustomize-tag.sh` via internal service URL. Uses `forgejo_token` secret, `OVERLAY=westsidekingsandqueens`, triggers only on push to main. ## Test Plan - [x] `forgejo_token` secret exists in Woodpecker for this repo (confirmed: scoped to `push` events) - [ ] Merge to main and confirm the pipeline runs all three steps: validate, build-and-push, update-kustomize-tag - [ ] Verify a commit appears in `pal-e-deployments` updating the westsidekingsandqueens overlay tag - [ ] Verify ArgoCD picks up the new tag and syncs the deployment ## Review Checklist - [x] Passed automated review-fix loop - [x] No secrets committed - [x] No unnecessary file changes - [x] Commit messages are descriptive ## Related Notes - `forgejo_admin/westside-app #123` -- the Forgejo issue this PR implements (Closes #123) - `westside-app` -- the project this work belongs to - Template: `pal-e-platform/scripts/woodpecker-update-tag-step.yaml` - Script: `pal-e-platform/scripts/update-kustomize-tag.sh`
feat: add update-kustomize-tag Woodpecker step after build
All checks were successful
ci/woodpecker/pr/woodpecker Pipeline was successful
47ea34e278
After build-and-push completes on main, this step downloads and runs
the canonical update-kustomize-tag.sh script from pal-e-platform to
bump the image tag in pal-e-deployments overlays/westsidekingsandqueens/prod.
This closes the CD loop so ArgoCD picks up new images automatically.

Closes #123

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Author
Owner

QA Review

Diff Analysis (1 file, +17 lines)

The new update-kustomize-tag step in .woodpecker.yaml is reviewed against the canonical template at pal-e-platform/scripts/woodpecker-update-tag-step.yaml and the script at pal-e-platform/scripts/update-kustomize-tag.sh.

Checklist

  • Template conformance -- Step matches the canonical template exactly (image, environment block structure, commands, depends_on, when filter)
  • Overlay value -- westsidekingsandqueens matches the template mapping comment and the existing repo: westsidekingsandqueens/app in the build step
  • Environment vars -- All three required vars provided: FORGEJO_TOKEN (from secret), OVERLAY, IMAGE_TAG (from CI_COMMIT_SHA)
  • Secret exists -- forgejo_token confirmed in Woodpecker repo secrets, scoped to push events
  • Internal URL -- Uses forgejo-http.forgejo.svc.cluster.local:80 (cluster-internal), consistent with the clone step and the script's default FORGEJO_HOST
  • depends_on -- Correctly depends on build-and-push, will not run unless build succeeds
  • when filter -- event: push, branch: main ensures this only runs on main merges, not PRs or manual triggers (intentional: manual builds should not auto-deploy)
  • No secrets in diff -- Only secret reference via from_secret, no tokens or credentials exposed
  • No unrelated changes -- Single file, single purpose

Notes

  • No issues found. The step is a clean copy of the canonical template with the correct overlay value substituted.

VERDICT: APPROVE

## QA Review ### Diff Analysis (1 file, +17 lines) The new `update-kustomize-tag` step in `.woodpecker.yaml` is reviewed against the canonical template at `pal-e-platform/scripts/woodpecker-update-tag-step.yaml` and the script at `pal-e-platform/scripts/update-kustomize-tag.sh`. ### Checklist - [x] **Template conformance** -- Step matches the canonical template exactly (image, environment block structure, commands, depends_on, when filter) - [x] **Overlay value** -- `westsidekingsandqueens` matches the template mapping comment and the existing `repo: westsidekingsandqueens/app` in the build step - [x] **Environment vars** -- All three required vars provided: `FORGEJO_TOKEN` (from secret), `OVERLAY`, `IMAGE_TAG` (from `CI_COMMIT_SHA`) - [x] **Secret exists** -- `forgejo_token` confirmed in Woodpecker repo secrets, scoped to `push` events - [x] **Internal URL** -- Uses `forgejo-http.forgejo.svc.cluster.local:80` (cluster-internal), consistent with the clone step and the script's default `FORGEJO_HOST` - [x] **depends_on** -- Correctly depends on `build-and-push`, will not run unless build succeeds - [x] **when filter** -- `event: push, branch: main` ensures this only runs on main merges, not PRs or manual triggers (intentional: manual builds should not auto-deploy) - [x] **No secrets in diff** -- Only secret reference via `from_secret`, no tokens or credentials exposed - [x] **No unrelated changes** -- Single file, single purpose ### Notes - No issues found. The step is a clean copy of the canonical template with the correct overlay value substituted. **VERDICT: APPROVE**
Author
Owner

PR #124 Review

DOMAIN REVIEW

Domain: Woodpecker CI / k8s CD pipeline (YAML)

This PR adds a single Woodpecker step (update-kustomize-tag) to .woodpecker.yaml. The step downloads and executes the canonical update-kustomize-tag.sh script from pal-e-platform, which handles the clone-sed-commit-push cycle with retry logic.

Template conformance: The step is a near-exact copy of the canonical template at pal-e-platform/scripts/woodpecker-update-tag-step.yaml. All structural elements match: image (alpine/git:latest), environment variables (FORGEJO_TOKEN from secret, OVERLAY, IMAGE_TAG), commands (wget + sh), depends_on: build-and-push, and the when clause (event: push, branch: main).

Cross-repo consistency: Compared against the same step already shipped in pal-e-docs/.woodpecker.yaml and pal-e-app/.woodpecker.yaml -- the structure is identical, differing only in the OVERLAY value (westsidekingsandqueens here, which matches the overlay mapping in the template comments).

Target overlay verified: pal-e-deployments/overlays/westsidekingsandqueens/prod/kustomization.yaml exists and contains a newTag field at the expected two-space indent, which the script's sed pattern will match correctly.

Secret handling: forgejo_token is referenced via from_secret, not hardcoded. No plaintext credentials anywhere in the diff.

Script safety: The canonical script at pal-e-platform/scripts/update-kustomize-tag.sh uses set -eu, validates all three required env vars, handles idempotent no-op (tag already up to date), and retries push up to 3 times with rebase for concurrent pipeline conflicts.

BLOCKERS

None.

  • No new functionality requiring test coverage (this is CI pipeline config, not application code)
  • No unvalidated user input
  • No secrets or credentials in code
  • No DRY violation -- uses the canonical shared script rather than inlining logic

NITS

  1. manual event missing from when clause: The build-and-push step triggers on event: [push, manual], but update-kustomize-tag triggers on event: push only. This matches the canonical template, so it is consistent. However, a manual rebuild on main would push a new image to Harbor but would NOT update the kustomize tag, leaving the deployment out of sync. Consider adding manual to close that gap. (Non-blocking because it matches the template -- if this is intentional, it should be documented in the template itself.)

  2. Stale PR #113: PR #113 (feat: auto-update kustomize image tag after build (#204)) is an older attempt at the same functionality that inlines all logic (no shared script, no retry, different secret name ci_forgejo_token, hardcoded push URL). It should be closed now that PR #124 supersedes it with the canonical pattern.

SOP COMPLIANCE

  • Branch named after issue (123-update-kustomize-tag references issue #123)
  • PR body follows template (Summary, Changes, Test Plan, Review Checklist, Related Notes)
  • Related section references the parent issue (Closes #123)
  • No secrets committed
  • No unnecessary file changes (1 file, 17 additions, 0 deletions -- precisely scoped)
  • Commit messages are descriptive

Missing from Related: no plan slug referenced. This appears to be standalone board work (not tied to a multi-phase plan), which is acceptable per kanban flow.

PROCESS OBSERVATIONS

  • Deployment frequency: This is a CD enablement change. Once merged, every push to main will auto-update the kustomize overlay and trigger ArgoCD sync, eliminating manual image tag bumps. Directly improves deployment frequency.
  • Change failure risk: Low. The canonical script has retry logic, idempotent no-op handling, and [skip ci] commit messages to prevent infinite pipeline loops. The pattern is already proven in pal-e-docs and pal-e-app.
  • Stale PR cleanup: PR #113 should be closed to avoid confusion. It represents the pre-canonical approach that this PR correctly replaces.
  • Test plan: Two of four test plan items are unchecked (post-merge validation). These are runtime validation items that can only be verified after merge, which is appropriate.

VERDICT: APPROVED

## PR #124 Review ### DOMAIN REVIEW **Domain: Woodpecker CI / k8s CD pipeline (YAML)** This PR adds a single Woodpecker step (`update-kustomize-tag`) to `.woodpecker.yaml`. The step downloads and executes the canonical `update-kustomize-tag.sh` script from `pal-e-platform`, which handles the clone-sed-commit-push cycle with retry logic. **Template conformance**: The step is a near-exact copy of the canonical template at `pal-e-platform/scripts/woodpecker-update-tag-step.yaml`. All structural elements match: image (`alpine/git:latest`), environment variables (`FORGEJO_TOKEN` from secret, `OVERLAY`, `IMAGE_TAG`), commands (wget + sh), `depends_on: build-and-push`, and the `when` clause (`event: push`, `branch: main`). **Cross-repo consistency**: Compared against the same step already shipped in `pal-e-docs/.woodpecker.yaml` and `pal-e-app/.woodpecker.yaml` -- the structure is identical, differing only in the `OVERLAY` value (`westsidekingsandqueens` here, which matches the overlay mapping in the template comments). **Target overlay verified**: `pal-e-deployments/overlays/westsidekingsandqueens/prod/kustomization.yaml` exists and contains a `newTag` field at the expected two-space indent, which the script's sed pattern will match correctly. **Secret handling**: `forgejo_token` is referenced via `from_secret`, not hardcoded. No plaintext credentials anywhere in the diff. **Script safety**: The canonical script at `pal-e-platform/scripts/update-kustomize-tag.sh` uses `set -eu`, validates all three required env vars, handles idempotent no-op (tag already up to date), and retries push up to 3 times with rebase for concurrent pipeline conflicts. ### BLOCKERS None. - No new functionality requiring test coverage (this is CI pipeline config, not application code) - No unvalidated user input - No secrets or credentials in code - No DRY violation -- uses the canonical shared script rather than inlining logic ### NITS 1. **`manual` event missing from `when` clause**: The `build-and-push` step triggers on `event: [push, manual]`, but `update-kustomize-tag` triggers on `event: push` only. This matches the canonical template, so it is consistent. However, a manual rebuild on main would push a new image to Harbor but would NOT update the kustomize tag, leaving the deployment out of sync. Consider adding `manual` to close that gap. (Non-blocking because it matches the template -- if this is intentional, it should be documented in the template itself.) 2. **Stale PR #113**: PR #113 (`feat: auto-update kustomize image tag after build (#204)`) is an older attempt at the same functionality that inlines all logic (no shared script, no retry, different secret name `ci_forgejo_token`, hardcoded push URL). It should be closed now that PR #124 supersedes it with the canonical pattern. ### SOP COMPLIANCE - [x] Branch named after issue (`123-update-kustomize-tag` references issue #123) - [x] PR body follows template (Summary, Changes, Test Plan, Review Checklist, Related Notes) - [x] Related section references the parent issue (`Closes #123`) - [x] No secrets committed - [x] No unnecessary file changes (1 file, 17 additions, 0 deletions -- precisely scoped) - [x] Commit messages are descriptive Missing from Related: no plan slug referenced. This appears to be standalone board work (not tied to a multi-phase plan), which is acceptable per kanban flow. ### PROCESS OBSERVATIONS - **Deployment frequency**: This is a CD enablement change. Once merged, every push to `main` will auto-update the kustomize overlay and trigger ArgoCD sync, eliminating manual image tag bumps. Directly improves deployment frequency. - **Change failure risk**: Low. The canonical script has retry logic, idempotent no-op handling, and `[skip ci]` commit messages to prevent infinite pipeline loops. The pattern is already proven in `pal-e-docs` and `pal-e-app`. - **Stale PR cleanup**: PR #113 should be closed to avoid confusion. It represents the pre-canonical approach that this PR correctly replaces. - **Test plan**: Two of four test plan items are unchecked (post-merge validation). These are runtime validation items that can only be verified after merge, which is appropriate. ### VERDICT: APPROVED
forgejo_admin deleted branch 123-update-kustomize-tag 2026-03-27 21:11:51 +00:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
forgejo_admin/westside-app!124
No description provided.