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

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

Summary

  • Adds an update-kustomize-tag step to the Woodpecker pipeline that runs after build-and-push
  • On push to main, downloads the canonical script from pal-e-platform and updates the basketball-api overlay in pal-e-deployments
  • ArgoCD picks up the kustomization change automatically, completing the CI/CD loop

Changes

  • .woodpecker.yaml: Added update-kustomize-tag step with depends_on: build-and-push, OVERLAY: basketball-api, IMAGE_TAG: ${CI_COMMIT_SHA}, and forgejo_token secret. Gated to push-to-main only.

Test Plan

  • Verified forgejo_token secret exists in Woodpecker repo secrets (scoped to push events)
  • Verified OVERLAY value (basketball-api) matches the script's path construction (overlays/${OVERLAY}/${OVERLAY_ENV}/kustomization.yaml where OVERLAY_ENV defaults to prod)
  • Step uses depends_on: build-and-push so it only runs after successful image push
  • Step gated by when: event: push, branch: main so it won't run on PRs
  • Merge to main and verify Woodpecker runs the step successfully

Review Checklist

  • No secrets committed
  • No unnecessary file changes
  • Commit messages are descriptive
  • Step matches canonical template from pal-e-platform/scripts/woodpecker-update-tag-step.yaml
  • Closes #190
  • pal-e-platform -- canonical script and step template live here
## Summary - Adds an `update-kustomize-tag` step to the Woodpecker pipeline that runs after `build-and-push` - On push to main, downloads the canonical script from pal-e-platform and updates the `basketball-api` overlay in pal-e-deployments - ArgoCD picks up the kustomization change automatically, completing the CI/CD loop ## Changes - `.woodpecker.yaml`: Added `update-kustomize-tag` step with `depends_on: build-and-push`, `OVERLAY: basketball-api`, `IMAGE_TAG: ${CI_COMMIT_SHA}`, and `forgejo_token` secret. Gated to push-to-main only. ## Test Plan - [x] Verified `forgejo_token` secret exists in Woodpecker repo secrets (scoped to `push` events) - [x] Verified OVERLAY value (`basketball-api`) matches the script's path construction (`overlays/${OVERLAY}/${OVERLAY_ENV}/kustomization.yaml` where OVERLAY_ENV defaults to `prod`) - [x] Step uses `depends_on: build-and-push` so it only runs after successful image push - [x] Step gated by `when: event: push, branch: main` so it won't run on PRs - [ ] Merge to main and verify Woodpecker runs the step successfully ## Review Checklist - [x] No secrets committed - [x] No unnecessary file changes - [x] Commit messages are descriptive - [x] Step matches canonical template from `pal-e-platform/scripts/woodpecker-update-tag-step.yaml` ## Related Notes - Closes #190 - `pal-e-platform` -- canonical script and step template live here
feat: add update-kustomize-tag Woodpecker step after build
All checks were successful
ci/woodpecker/pr/woodpecker Pipeline was successful
dc0a53a4cc
After image push to Harbor, this step downloads the canonical
update-kustomize-tag.sh script from pal-e-platform and updates
the basketball-api overlay in pal-e-deployments so ArgoCD picks
up the new tag automatically.

Closes #190

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

QA Review -- PR #192

Diff Analysis

Single file change: .woodpecker.yaml (+17 lines). Adds the update-kustomize-tag step after build-and-push.

Verification

  • Template conformance: Step matches pal-e-platform/scripts/woodpecker-update-tag-step.yaml canonical template exactly
  • OVERLAY value: basketball-api matches the template mapping comment (line 8) and the script's path construction (overlays/basketball-api/prod/kustomization.yaml)
  • Secret: forgejo_token exists in Woodpecker repo secrets, scoped to push events
  • Dependency chain: depends_on: build-and-push ensures image is pushed before tag update runs
  • Gate: when: event: push, branch: main prevents execution on PRs
  • No secrets committed: Confirmed -- token injected via from_secret

Nits

None.

VERDICT: APPROVE

## QA Review -- PR #192 ### Diff Analysis Single file change: `.woodpecker.yaml` (+17 lines). Adds the `update-kustomize-tag` step after `build-and-push`. ### Verification - **Template conformance:** Step matches `pal-e-platform/scripts/woodpecker-update-tag-step.yaml` canonical template exactly - **OVERLAY value:** `basketball-api` matches the template mapping comment (line 8) and the script's path construction (`overlays/basketball-api/prod/kustomization.yaml`) - **Secret:** `forgejo_token` exists in Woodpecker repo secrets, scoped to `push` events - **Dependency chain:** `depends_on: build-and-push` ensures image is pushed before tag update runs - **Gate:** `when: event: push, branch: main` prevents execution on PRs - **No secrets committed:** Confirmed -- token injected via `from_secret` ### Nits None. **VERDICT: APPROVE**
Author
Owner

PR #192 Review

DOMAIN REVIEW

Tech stack: Woodpecker CI pipeline YAML (CI/CD domain).

The PR adds a single update-kustomize-tag step to .woodpecker.yaml that downloads and runs the canonical script from pal-e-platform/scripts/update-kustomize-tag.sh after a successful build-and-push step. This completes the CI/CD loop: push to main -> build image -> push to Harbor -> update kustomize overlay -> ArgoCD syncs.

Verified against canonical template (pal-e-platform/scripts/woodpecker-update-tag-step.yaml):

  • Step structure matches the template exactly (image, environment, commands, depends_on, when).
  • OVERLAY value basketball-api matches the template's mapping table comment on line 8.

Verified target overlay exists (pal-e-deployments/overlays/basketball-api/prod/kustomization.yaml):

  • File exists with two newTag entries (lines 76, 78). The canonical script's sed pattern (s/^\( newTag:\s*\).*$/\1${IMAGE_TAG}/) will correctly update both.

Pipeline gating is correct:

  • depends_on: build-and-push ensures the step only runs after a successful image push.
  • when: event: push, branch: main prevents execution on pull request events.
  • The secret forgejo_token is referenced via from_secret, not hardcoded.

Script download URL uses the internal cluster service URL (forgejo-http.forgejo.svc.cluster.local:80) which is correct for Woodpecker agents running in-cluster.

BLOCKERS

None.

NITS

  1. alpine/git:latest tag: Using :latest is technically non-deterministic. However, this matches the canonical template exactly, so any pinning decision should be made at the template level in pal-e-platform, not per-consumer. Not blocking.

  2. PR body template: The sections use "Review Checklist" and "Related Notes" instead of the SOP template's "Related" section. The content is there but the heading names differ slightly from the SOP template (## Related vs ## Related Notes). Minor.

SOP COMPLIANCE

  • Branch named after issue (190-update-kustomize-tag references #190)
  • PR body has Summary, Changes, Test Plan, Related sections (present, headings slightly differ)
  • Related section references a plan slug (references pal-e-platform as source repo -- no plan slug, but this is a standalone CI task, not plan-driven work; acceptable)
  • No secrets committed (token via from_secret only)
  • No unnecessary file changes (1 file, 17 additions, 0 deletions -- tightly scoped)
  • Commit messages are descriptive

PROCESS OBSERVATIONS

This step closes the CI/CD loop for basketball-api. Previously, image tags in pal-e-deployments had to be updated manually or by a separate process. With this change, every merge to main will automatically propagate the new image tag to ArgoCD, improving deployment frequency (DORA DF metric).

The canonical script pattern (download from pal-e-platform at runtime) is a good DRY strategy -- updates to the script propagate to all consumers without per-repo PRs. The retry logic in the script handles concurrent push conflicts gracefully.

Post-merge validation (unchecked item in Test Plan) is the remaining gate: verify the Woodpecker pipeline actually runs the step successfully on the first merge to main.

VERDICT: APPROVED

## PR #192 Review ### DOMAIN REVIEW **Tech stack**: Woodpecker CI pipeline YAML (CI/CD domain). The PR adds a single `update-kustomize-tag` step to `.woodpecker.yaml` that downloads and runs the canonical script from `pal-e-platform/scripts/update-kustomize-tag.sh` after a successful `build-and-push` step. This completes the CI/CD loop: push to main -> build image -> push to Harbor -> update kustomize overlay -> ArgoCD syncs. **Verified against canonical template** (`pal-e-platform/scripts/woodpecker-update-tag-step.yaml`): - Step structure matches the template exactly (image, environment, commands, depends_on, when). - OVERLAY value `basketball-api` matches the template's mapping table comment on line 8. **Verified target overlay exists** (`pal-e-deployments/overlays/basketball-api/prod/kustomization.yaml`): - File exists with two `newTag` entries (lines 76, 78). The canonical script's sed pattern (`s/^\( newTag:\s*\).*$/\1${IMAGE_TAG}/`) will correctly update both. **Pipeline gating is correct**: - `depends_on: build-and-push` ensures the step only runs after a successful image push. - `when: event: push, branch: main` prevents execution on pull request events. - The secret `forgejo_token` is referenced via `from_secret`, not hardcoded. **Script download URL** uses the internal cluster service URL (`forgejo-http.forgejo.svc.cluster.local:80`) which is correct for Woodpecker agents running in-cluster. ### BLOCKERS None. ### NITS 1. **`alpine/git:latest` tag**: Using `:latest` is technically non-deterministic. However, this matches the canonical template exactly, so any pinning decision should be made at the template level in `pal-e-platform`, not per-consumer. Not blocking. 2. **PR body template**: The sections use "Review Checklist" and "Related Notes" instead of the SOP template's "Related" section. The content is there but the heading names differ slightly from the SOP template (`## Related` vs `## Related Notes`). Minor. ### SOP COMPLIANCE - [x] Branch named after issue (`190-update-kustomize-tag` references #190) - [x] PR body has Summary, Changes, Test Plan, Related sections (present, headings slightly differ) - [ ] Related section references a plan slug (references `pal-e-platform` as source repo -- no plan slug, but this is a standalone CI task, not plan-driven work; acceptable) - [x] No secrets committed (token via `from_secret` only) - [x] No unnecessary file changes (1 file, 17 additions, 0 deletions -- tightly scoped) - [x] Commit messages are descriptive ### PROCESS OBSERVATIONS This step closes the CI/CD loop for basketball-api. Previously, image tags in `pal-e-deployments` had to be updated manually or by a separate process. With this change, every merge to main will automatically propagate the new image tag to ArgoCD, improving deployment frequency (DORA DF metric). The canonical script pattern (download from pal-e-platform at runtime) is a good DRY strategy -- updates to the script propagate to all consumers without per-repo PRs. The retry logic in the script handles concurrent push conflicts gracefully. Post-merge validation (unchecked item in Test Plan) is the remaining gate: verify the Woodpecker pipeline actually runs the step successfully on the first merge to main. ### VERDICT: APPROVED
forgejo_admin deleted branch 190-update-kustomize-tag 2026-03-27 21:11:52 +00:00
Sign in to join this conversation.
No description provided.