Woodpecker: expose bundle-cache PVC volume to pipeline pods

ldraney commented

2026-06-10 01:52:20 +00:00

Owner

Summary

One-line Terraform change to expose the woodpecker-bundle-cache PVC to Woodpecker pipeline pods, enabling persistent gem caching for landscaping-assistant CI builds.

Closes #417

Changes

terraform/modules/ci/main.tf: Add WOODPECKER_BACKEND_K8S_VOLUMES env var to the Woodpecker agent config. Maps the bundle-cache volume name (referenced in landscaping-assistant's .woodpecker.yaml) to the woodpecker-bundle-cache PVC (already created in cluster).

Test Plan

terraform plan shows only the agent env var addition
terraform apply rolls the agent pod with the new config
Next landscaping-assistant pipeline populates /cache/bundle on first run
Subsequent pipelines restore gems from cache (~10s vs ~90s)

Review Checklist

Single env var addition, no other changes
PVC already exists in cluster
ReadWriteOnce is correct for single-agent setup
Feature flag: N/A

landscaping-assistant#187 / PR #188 — pipeline optimization that added gem cache to .woodpecker.yaml
PVC created via kubectl apply (not yet Terraform-managed)

## Summary One-line Terraform change to expose the `woodpecker-bundle-cache` PVC to Woodpecker pipeline pods, enabling persistent gem caching for landscaping-assistant CI builds. Closes #417 ## Changes - **terraform/modules/ci/main.tf**: Add `WOODPECKER_BACKEND_K8S_VOLUMES` env var to the Woodpecker agent config. Maps the `bundle-cache` volume name (referenced in landscaping-assistant's `.woodpecker.yaml`) to the `woodpecker-bundle-cache` PVC (already created in cluster). ## Test Plan - [ ] `terraform plan` shows only the agent env var addition - [ ] `terraform apply` rolls the agent pod with the new config - [ ] Next landscaping-assistant pipeline populates `/cache/bundle` on first run - [ ] Subsequent pipelines restore gems from cache (~10s vs ~90s) ## Review Checklist - [x] Single env var addition, no other changes - [x] PVC already exists in cluster - [x] ReadWriteOnce is correct for single-agent setup - [ ] Feature flag: N/A ## Related Notes - landscaping-assistant#187 / PR #188 — pipeline optimization that added gem cache to `.woodpecker.yaml` - PVC created via `kubectl apply` (not yet Terraform-managed)

ldraney added 1 commit

2026-06-10 01:52:21 +00:00

Add bundle-cache PVC volume to Woodpecker agent

ci/woodpecker/push/terraform Pipeline was successful

Details

ci/woodpecker/pr/terraform Pipeline was successful

Details

ci/woodpecker/pull_request_closed/terraform Pipeline was successful

Details

bab932d3fc

Exposes the woodpecker-bundle-cache PVC (already created in cluster)
to pipeline pods via WOODPECKER_BACKEND_K8S_VOLUMES. This lets the
landscaping-assistant .woodpecker.yaml mount it at /cache/bundle to
persist gems across pipeline runs (~60-80s savings per build).

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

ldraney commented

2026-06-10 01:54:10 +00:00

Author

Owner

PR #418 Review

DOMAIN REVIEW

Tech stack: Terraform / Helm / Kubernetes

JSON escaping correctness: Verified. The HCL string "[{\\\"name\\\":\\\"bundle-cache\\\",\\\"persistentVolumeClaim\\\":{\\\"claimName\\\":\\\"woodpecker-bundle-cache\\\"}}]" correctly unescapes through two layers:

HCL: \\\" -> \" (literal backslash-quote in the string value)
Env var consumed as JSON: [{"name":"bundle-cache","persistentVolumeClaim":{"claimName":"woodpecker-bundle-cache"}}]

This produces valid Kubernetes volume JSON.

Volume name cross-reference: Confirmed. landscaping-assistant PR #188 (merged) added backend_options.kubernetes.volumeMounts with name: bundle-cache and mountPath: /cache/bundle to .woodpecker.yaml. The volume name bundle-cache in this PR matches exactly.

PVC claim name cross-reference: Confirmed. PR #188's inline comments specify the PVC as woodpecker-bundle-cache in the woodpecker namespace, which matches claimName here.

ReadWriteOnce access mode: Appropriate. The PR body notes single-agent setup. With WOODPECKER_MAX_WORKFLOWS = "4" visible in the surrounding config, concurrent steps could attempt simultaneous access. However, RWO permits multiple pods on the same node, and Woodpecker agent pods schedule to the same node in this setup. If the agent is ever scaled to multiple replicas on different nodes, this would need to become ReadWriteMany or use per-node caching -- but that is a future concern, not a current blocker. PR #405 already scaled agents to 2 replicas, so this is worth monitoring.

PVC not Terraform-managed: The PR body notes "PVC created via kubectl apply (not yet Terraform-managed)". This is an infrastructure drift risk -- the PVC exists outside Terraform state, so terraform destroy or namespace cleanup would not account for it. Not a blocker for this PR, but should be tracked as follow-up work.

BLOCKERS

None.

NITS

PVC outside Terraform state: Consider a follow-up ticket to import the woodpecker-bundle-cache PVC into Terraform as a kubernetes_persistent_volume_claim resource. Having infra declared in two places (Terraform + manual kubectl) creates drift risk.
Multi-agent RWO concern: PR #405 scaled Woodpecker agents to 2 replicas. If those replicas land on different nodes, the RWO PVC will fail to mount on the second node. Worth a comment in the code or a monitoring note. Current risk is low if both agents schedule to the same node.
Alignment: The existing env vars use padded alignment for readability. The new line follows this convention correctly -- no issue here.

SOP COMPLIANCE

PR body has: Summary, Changes, Test Plan, Related -- all present and well-structured
No secrets committed
No unnecessary file changes (single file, single line -- scope is tight)
Commit message is descriptive (PR title matches intent)
Closes #417 present in body

PROCESS OBSERVATIONS

Deployment frequency: Minimal risk, one env var addition. Rollback is straightforward (remove the line, re-apply).
Change failure risk: Low. The volume mount is additive -- existing pipelines without bundle-cache volume references are unaffected. Only landscaping-assistant's .woodpecker.yaml references this volume name.
Cross-repo coordination: This PR completes a two-repo change started in landscaping-assistant PR #188. The pipeline-side changes (PR #188) already handle the case where the volume is not available (2>/dev/null || true), so ordering is safe -- this PR can land independently.
Documentation gap: The PVC creation is documented only in .woodpecker.yaml comments in the other repo. A brief note in pal-e-platform docs about CI volume provisioning would help future operators.

VERDICT: APPROVED

## PR #418 Review ### DOMAIN REVIEW **Tech stack:** Terraform / Helm / Kubernetes **JSON escaping correctness:** Verified. The HCL string `"[{\\\"name\\\":\\\"bundle-cache\\\",\\\"persistentVolumeClaim\\\":{\\\"claimName\\\":\\\"woodpecker-bundle-cache\\\"}}]"` correctly unescapes through two layers: 1. HCL: `\\\"` -> `\"` (literal backslash-quote in the string value) 2. Env var consumed as JSON: `[{"name":"bundle-cache","persistentVolumeClaim":{"claimName":"woodpecker-bundle-cache"}}]` This produces valid Kubernetes volume JSON. **Volume name cross-reference:** Confirmed. `landscaping-assistant` PR #188 (merged) added `backend_options.kubernetes.volumeMounts` with `name: bundle-cache` and `mountPath: /cache/bundle` to `.woodpecker.yaml`. The volume name `bundle-cache` in this PR matches exactly. **PVC claim name cross-reference:** Confirmed. PR #188's inline comments specify the PVC as `woodpecker-bundle-cache` in the `woodpecker` namespace, which matches `claimName` here. **ReadWriteOnce access mode:** Appropriate. The PR body notes single-agent setup. With `WOODPECKER_MAX_WORKFLOWS = "4"` visible in the surrounding config, concurrent steps could attempt simultaneous access. However, RWO permits multiple pods on the same node, and Woodpecker agent pods schedule to the same node in this setup. If the agent is ever scaled to multiple replicas on different nodes, this would need to become ReadWriteMany or use per-node caching -- but that is a future concern, not a current blocker. PR #405 already scaled agents to 2 replicas, so this is worth monitoring. **PVC not Terraform-managed:** The PR body notes "PVC created via `kubectl apply` (not yet Terraform-managed)". This is an infrastructure drift risk -- the PVC exists outside Terraform state, so `terraform destroy` or namespace cleanup would not account for it. Not a blocker for this PR, but should be tracked as follow-up work. ### BLOCKERS None. ### NITS 1. **PVC outside Terraform state:** Consider a follow-up ticket to import the `woodpecker-bundle-cache` PVC into Terraform as a `kubernetes_persistent_volume_claim` resource. Having infra declared in two places (Terraform + manual kubectl) creates drift risk. 2. **Multi-agent RWO concern:** PR #405 scaled Woodpecker agents to 2 replicas. If those replicas land on different nodes, the RWO PVC will fail to mount on the second node. Worth a comment in the code or a monitoring note. Current risk is low if both agents schedule to the same node. 3. **Alignment:** The existing env vars use padded alignment for readability. The new line follows this convention correctly -- no issue here. ### SOP COMPLIANCE - [x] PR body has: Summary, Changes, Test Plan, Related -- all present and well-structured - [x] No secrets committed - [x] No unnecessary file changes (single file, single line -- scope is tight) - [x] Commit message is descriptive (PR title matches intent) - [x] `Closes #417` present in body ### PROCESS OBSERVATIONS - **Deployment frequency:** Minimal risk, one env var addition. Rollback is straightforward (remove the line, re-apply). - **Change failure risk:** Low. The volume mount is additive -- existing pipelines without `bundle-cache` volume references are unaffected. Only landscaping-assistant's `.woodpecker.yaml` references this volume name. - **Cross-repo coordination:** This PR completes a two-repo change started in landscaping-assistant PR #188. The pipeline-side changes (PR #188) already handle the case where the volume is not available (`2>/dev/null || true`), so ordering is safe -- this PR can land independently. - **Documentation gap:** The PVC creation is documented only in `.woodpecker.yaml` comments in the other repo. A brief note in pal-e-platform docs about CI volume provisioning would help future operators. ### VERDICT: APPROVED