Add Woodpecker CI pipeline for container builds

ldraney commented

2026-05-24 14:12:55 +00:00

Owner

Summary

Adds .woodpecker.yaml with Kaniko build triggered on push to main
Uses in-cluster Forgejo clone, pushes to Harbor with layer caching
Tags images with commit SHA for traceability

Changes

.woodpecker.yaml: new file — clone step (in-cluster Forgejo DNS) + Kaniko build-and-push step

Test Plan

Merge pal-e-services PR and run tofu apply first (creates Harbor project + CI robot)
Configure Woodpecker secrets (harbor_username, harbor_password) from tofu output
Merge this PR and verify pipeline triggers on Woodpecker
Confirm image appears in Harbor at palinks/app:$SHA

Review Checklist

Passed automated review-fix loop
No secrets committed
No unnecessary file changes
Commit messages are descriptive

Closes #6
ldraney/pal-e-services #85 — dependency: Harbor project provisioning
palinks — project page

## Summary - Adds `.woodpecker.yaml` with Kaniko build triggered on push to main - Uses in-cluster Forgejo clone, pushes to Harbor with layer caching - Tags images with commit SHA for traceability ## Changes - `.woodpecker.yaml`: new file — clone step (in-cluster Forgejo DNS) + Kaniko build-and-push step ## Test Plan - [ ] Merge pal-e-services PR and run `tofu apply` first (creates Harbor project + CI robot) - [ ] Configure Woodpecker secrets (`harbor_username`, `harbor_password`) from tofu output - [ ] Merge this PR and verify pipeline triggers on Woodpecker - [ ] Confirm image appears in Harbor at `palinks/app:$SHA` ## Review Checklist - [ ] Passed automated review-fix loop - [ ] No secrets committed - [ ] No unnecessary file changes - [ ] Commit messages are descriptive ## Related Notes - Closes #6 - `ldraney/pal-e-services #85` — dependency: Harbor project provisioning - `palinks` — project page

ldraney added 1 commit

2026-05-24 14:12:55 +00:00

Add Woodpecker CI pipeline for container builds 575049773c

Kaniko build on push to main, tags with commit SHA, pushes to Harbor
with layer caching. Uses in-cluster Forgejo clone.

Closes #6

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

ldraney commented

2026-05-24 14:14:19 +00:00

Author

Owner

PR #7 Review

DOMAIN REVIEW

Tech stack: Woodpecker CI / Kaniko / Harbor (CI/CD pipeline config)

Correctness -- pipeline matches docs exactly. The .woodpecker.yaml is an exact match with the pipeline documented in docs/pipeline.md (lines 108-137). Every detail aligns:

Trigger: push to main only -- correct
Clone: in-cluster Forgejo DNS (forgejo-http.forgejo.svc.cluster.local:80) with --depth 1 shallow fetch -- correct pattern, avoids external network hop
sleep 2 in clone step -- acceptable timing guard for Forgejo DNS readiness in-cluster
Kaniko plugin woodpeckerci/plugin-kaniko:2.3.0 -- pinned version, good
Image tag: ${CI_COMMIT_SHA} -- matches ArgoCD Image Updater expectations for SHA-based tracking
Cache: harbor.tail5b443a.ts.net/palinks/cache -- layer caching enabled, will speed up repeat builds
Secrets: from_secret: harbor_username / from_secret: harbor_password -- proper Woodpecker secret references, no plaintext credentials

Dockerfile compatibility: Confirmed. The Dockerfile is a proper multi-stage Rails build (ruby slim base, build stage with gems/bootsnap/assets, slim final stage running as non-root UID 1000). Kaniko will handle this correctly.

BLOCKERS

None.

No secrets or credentials in code -- harbor credentials use from_secret references
No unvalidated user input (CI config, not application code)
No DRY violations -- single file, first CI config in this repo
Test coverage N/A -- this is infrastructure config, not application code. The Test Plan in the PR body correctly lists manual verification steps (pipeline triggers, image appears in Harbor)

NITS

None. The file is clean, minimal, and follows the established pattern exactly.

SOP COMPLIANCE

Branch named after issue: 6-woodpecker-ci references issue #6
PR body follows template: Summary, Changes, Test Plan, Review Checklist, Related all present
Related references: closes #6, cross-references pal-e-services #85 (dependency), project page
No secrets committed: credentials use from_secret references
No unnecessary file changes: single file addition, 29 lines, zero scope creep
Commit messages: descriptive (PR title matches intent)
Pipeline documented: docs/pipeline.md already documents this exact config with architecture diagrams

PROCESS OBSERVATIONS

Dependency chain is documented: PR body correctly notes pal-e-services #85 must land first (Harbor project + CI robot provisioning via tofu). Good sequencing awareness.
Deployment frequency: This PR enables automated container builds -- once merged and the dependency chain completes, every push to main will produce a tagged image. This is the key enabler for the full GitOps pipeline described in docs/pipeline.md.
Change failure risk: Low. The pipeline is simple (clone + build + push), pinned to a specific Kaniko version, and uses established patterns. The manual test plan covers the verification path.

VERDICT: APPROVED

## PR #7 Review ### DOMAIN REVIEW **Tech stack**: Woodpecker CI / Kaniko / Harbor (CI/CD pipeline config) **Correctness -- pipeline matches docs exactly.** The `.woodpecker.yaml` is an exact match with the pipeline documented in `docs/pipeline.md` (lines 108-137). Every detail aligns: - Trigger: push to main only -- correct - Clone: in-cluster Forgejo DNS (`forgejo-http.forgejo.svc.cluster.local:80`) with `--depth 1` shallow fetch -- correct pattern, avoids external network hop - `sleep 2` in clone step -- acceptable timing guard for Forgejo DNS readiness in-cluster - Kaniko plugin `woodpeckerci/plugin-kaniko:2.3.0` -- pinned version, good - Image tag: `${CI_COMMIT_SHA}` -- matches ArgoCD Image Updater expectations for SHA-based tracking - Cache: `harbor.tail5b443a.ts.net/palinks/cache` -- layer caching enabled, will speed up repeat builds - Secrets: `from_secret: harbor_username` / `from_secret: harbor_password` -- proper Woodpecker secret references, no plaintext credentials **Dockerfile compatibility**: Confirmed. The Dockerfile is a proper multi-stage Rails build (ruby slim base, build stage with gems/bootsnap/assets, slim final stage running as non-root UID 1000). Kaniko will handle this correctly. ### BLOCKERS None. - No secrets or credentials in code -- harbor credentials use `from_secret` references - No unvalidated user input (CI config, not application code) - No DRY violations -- single file, first CI config in this repo - Test coverage N/A -- this is infrastructure config, not application code. The Test Plan in the PR body correctly lists manual verification steps (pipeline triggers, image appears in Harbor) ### NITS None. The file is clean, minimal, and follows the established pattern exactly. ### SOP COMPLIANCE - [x] Branch named after issue: `6-woodpecker-ci` references issue #6 - [x] PR body follows template: Summary, Changes, Test Plan, Review Checklist, Related all present - [x] Related references: closes #6, cross-references pal-e-services #85 (dependency), project page - [x] No secrets committed: credentials use `from_secret` references - [x] No unnecessary file changes: single file addition, 29 lines, zero scope creep - [x] Commit messages: descriptive (PR title matches intent) - [x] Pipeline documented: `docs/pipeline.md` already documents this exact config with architecture diagrams ### PROCESS OBSERVATIONS - **Dependency chain is documented**: PR body correctly notes pal-e-services #85 must land first (Harbor project + CI robot provisioning via tofu). Good sequencing awareness. - **Deployment frequency**: This PR enables automated container builds -- once merged and the dependency chain completes, every push to main will produce a tagged image. This is the key enabler for the full GitOps pipeline described in `docs/pipeline.md`. - **Change failure risk**: Low. The pipeline is simple (clone + build + push), pinned to a specific Kaniko version, and uses established patterns. The manual test plan covers the verification path. ### VERDICT: APPROVED