Add Woodpecker validation pipeline (tofu fmt + validate) #37

New issue

Closed

opened 2026-03-14 13:59:13 +00:00 by forgejo_admin · 0 comments

forgejo_admin commented

2026-03-14 13:59:13 +00:00

Owner

Lineage

plan-pal-e-platform → Phase 6 (CI Pipeline Hardening) → Phase 6.2 (Validation Pipeline)

Repo

forgejo_admin/pal-e-platform

User Story

As a developer submitting infrastructure changes
I want PRs to automatically run tofu fmt -check and tofu validate
So that formatting and syntax errors are caught before merge (Change Failure Rate)

Context

pal-e-platform has zero CI for Terraform. App repos (basketball-api, pal-e-docs, etc.) all have Woodpecker pipelines, but the infrastructure repos don't. This means formatting errors and syntax issues are only caught when someone manually runs tofu validate — or worse, at apply time.

This is the first CI gate for infrastructure code. It does NOT need state access or secrets — tofu init -backend=false downloads providers without connecting to the backend. tofu validate checks syntax only.

Key technical facts:

Woodpecker CI is deployed in the woodpecker namespace
Woodpecker uses the Kubernetes backend for pipeline execution
pal-e-platform repo is on Forgejo at forgejo_admin/pal-e-platform
The repo may or may not be activated in Woodpecker yet — check first
Terraform providers: hashicorp/helm, hashicorp/kubernetes, tailscale/tailscale, aminueza/minio
OpenTofu version in use: 1.11.5 (use a compatible image)

File Targets

Files to create:

.woodpecker.yaml — validation pipeline

Files NOT to touch:

terraform/ — no Terraform changes in this PR
salt/ — not relevant

Acceptance Criteria

.woodpecker.yaml exists in repo root with a validate step that:
- Uses ghcr.io/opentofu/opentofu:latest image (or a pinned version ≥1.9)
- Runs cd terraform && tofu init -backend=false
- Runs tofu fmt -check -recursive
- Runs tofu validate
Pipeline triggers on pull_request events
Pipeline does NOT trigger on push to main (that's Phase 6.4)
No secrets are required (backend=false means no state access)

Test Expectations

After merging this PR, create a test branch with a deliberately misformatted .tf file, open a PR, and verify Woodpecker shows a failure
Verify a properly formatted PR shows green

Constraints

Keep the pipeline minimal — only fmt + validate. Plan-on-PR (Phase 6.3) and apply-on-merge (Phase 6.4) are separate issues.
Use tofu init -backend=false to avoid needing any secrets or cluster access
The Woodpecker YAML should follow the same patterns used by other repos in the org (check basketball-api or pal-e-docs for reference if needed)
Do NOT add branch protection in this PR — that's a manual Forgejo admin step done after the pipeline is proven working

Checklist

PR opened with Closes #37 in body
No Terraform changes
.woodpecker.yaml is the only file added

project-pal-e-platform — project
phase-pal-e-platform-ci-6-2-validation-pipeline — phase note in pal-e-docs

### Lineage `plan-pal-e-platform` → Phase 6 (CI Pipeline Hardening) → Phase 6.2 (Validation Pipeline) ### Repo `forgejo_admin/pal-e-platform` ### User Story As a developer submitting infrastructure changes I want PRs to automatically run `tofu fmt -check` and `tofu validate` So that formatting and syntax errors are caught before merge (Change Failure Rate) ### Context pal-e-platform has zero CI for Terraform. App repos (basketball-api, pal-e-docs, etc.) all have Woodpecker pipelines, but the infrastructure repos don't. This means formatting errors and syntax issues are only caught when someone manually runs `tofu validate` — or worse, at apply time. This is the first CI gate for infrastructure code. It does NOT need state access or secrets — `tofu init -backend=false` downloads providers without connecting to the backend. `tofu validate` checks syntax only. Key technical facts: - Woodpecker CI is deployed in the `woodpecker` namespace - Woodpecker uses the Kubernetes backend for pipeline execution - pal-e-platform repo is on Forgejo at `forgejo_admin/pal-e-platform` - The repo may or may not be activated in Woodpecker yet — check first - Terraform providers: `hashicorp/helm`, `hashicorp/kubernetes`, `tailscale/tailscale`, `aminueza/minio` - OpenTofu version in use: 1.11.5 (use a compatible image) ### File Targets Files to create: - `.woodpecker.yaml` — validation pipeline Files NOT to touch: - `terraform/` — no Terraform changes in this PR - `salt/` — not relevant ### Acceptance Criteria - [ ] `.woodpecker.yaml` exists in repo root with a `validate` step that: - Uses `ghcr.io/opentofu/opentofu:latest` image (or a pinned version ≥1.9) - Runs `cd terraform && tofu init -backend=false` - Runs `tofu fmt -check -recursive` - Runs `tofu validate` - [ ] Pipeline triggers on `pull_request` events - [ ] Pipeline does NOT trigger on `push` to main (that's Phase 6.4) - [ ] No secrets are required (backend=false means no state access) ### Test Expectations - [ ] After merging this PR, create a test branch with a deliberately misformatted `.tf` file, open a PR, and verify Woodpecker shows a failure - [ ] Verify a properly formatted PR shows green ### Constraints - Keep the pipeline minimal — only fmt + validate. Plan-on-PR (Phase 6.3) and apply-on-merge (Phase 6.4) are separate issues. - Use `tofu init -backend=false` to avoid needing any secrets or cluster access - The Woodpecker YAML should follow the same patterns used by other repos in the org (check basketball-api or pal-e-docs for reference if needed) - Do NOT add branch protection in this PR — that's a manual Forgejo admin step done after the pipeline is proven working ### Checklist - [ ] PR opened with `Closes #37` in body - [ ] No Terraform changes - [ ] `.woodpecker.yaml` is the only file added ### Related - `project-pal-e-platform` — project - `phase-pal-e-platform-ci-6-2-validation-pipeline` — phase note in pal-e-docs