chore(woodpecker): pre-stage prune:disabled on the wp-pg CNPG objects (stage 1) #394

2026-07-25T03:55:52Z

claude-bot commented

2026-07-25 03:55:52 +00:00

Stage 1 of moving woodpecker off seed-woodpecker into its own dedicated KS (chosen clean approach) — the safety pre-stage, same two-step pattern proven on InfluxDB (#388/#390) but for a real Postgres cluster and the live CI app.

Adds kustomize.toolkit.fluxcd.io/prune: disabled to everything that the later ownership handoff must not prune:

DB objects (per-file under seed/woodpecker/, kept permanently as a data-guard):

Cluster/wp-pg — pruning deletes the DB's data PVCs (recoverable only from barman)
ObjectStore/wp-pg-store, ScheduledBackup/wp-pg-daily, ExternalSecret/hetzner-s3-creds

App objects (via commonAnnotations in apps/woodpecker/kustomization.yaml, transient — removed in the final stage): the woodpecker-ci Namespace, woodpecker-server/agent Deployments, Service, Ingress, PDB, NetworkPolicy, ResourceQuota/LimitRange, RBAC, ExternalSecret.

Accepted trade-off: commonAnnotations propagates into the two Deployments' pod templates, so this rolls woodpecker-server + agent once on merge (and once more when removed later). The maintainer confirmed a CI restart is fine. The DB (wp-pg) is a separate CNPG resource → untouched, no DB restart.

Verified: kubectl kustomize seed/woodpecker → 4 DB objects annotated; apps/woodpecker → all 13 objects annotated (15 incl. the 2 pod templates); wp-pg has healthy barman backups (last ~70m) as a backstop.

Remaining stages

create clusters/homelab/woodpecker.yaml (dedicated KS, cnpg-barman dep + CNPG health exprs), remove woodpecker/ from apps/kustomization.yaml, git mv DB into apps/woodpecker/, delete seed-woodpecker — nothing pruned, new KS adopts all
remove the transient commonAnnotations (app objects prunable again; DB keeps its guard)

**Stage 1** of moving woodpecker off `seed-woodpecker` into its own dedicated KS (chosen clean approach) — the safety pre-stage, same two-step pattern proven on InfluxDB (#388/#390) but for a real Postgres cluster **and** the live CI app. Adds `kustomize.toolkit.fluxcd.io/prune: disabled` to everything that the later ownership handoff must not prune: **DB objects** (per-file under `seed/woodpecker/`, kept permanently as a data-guard): - `Cluster/wp-pg` — pruning deletes the DB's data PVCs (recoverable only from barman) - `ObjectStore/wp-pg-store`, `ScheduledBackup/wp-pg-daily`, `ExternalSecret/hetzner-s3-creds` **App objects** (via `commonAnnotations` in `apps/woodpecker/kustomization.yaml`, transient — removed in the final stage): the `woodpecker-ci` Namespace, `woodpecker-server`/`agent` Deployments, Service, Ingress, PDB, NetworkPolicy, ResourceQuota/LimitRange, RBAC, ExternalSecret. **Accepted trade-off:** commonAnnotations propagates into the two Deployments' pod templates, so this rolls woodpecker-server + agent once on merge (and once more when removed later). The maintainer confirmed a CI restart is fine. The DB (`wp-pg`) is a separate CNPG resource → untouched, no DB restart. **Verified:** `kubectl kustomize seed/woodpecker` → 4 DB objects annotated; `apps/woodpecker` → all 13 objects annotated (15 incl. the 2 pod templates); wp-pg has healthy barman backups (last ~70m) as a backstop. ### Remaining stages 2. create `clusters/homelab/woodpecker.yaml` (dedicated KS, cnpg-barman dep + CNPG health exprs), remove `woodpecker/` from `apps/kustomization.yaml`, `git mv` DB into `apps/woodpecker/`, delete `seed-woodpecker` — nothing pruned, new KS adopts all 3. remove the transient `commonAnnotations` (app objects prunable again; DB keeps its guard)

claude-bot added 1 commit 2026-07-25 03:55:53 +00:00

chore(woodpecker): pre-stage prune:disabled on the wp-pg CNPG objects

ci/woodpecker/pr/pr-review Pipeline is pending

Details

a7b4e2b996

Stage 1 of moving woodpecker off seed-woodpecker into a dedicated woodpecker KS.
Adds kustomize.toolkit.fluxcd.io/prune: disabled, in place, to the four
data-bearing DB objects in seed/woodpecker/ so the later ownership handoff can
never prune them:

- Cluster/wp-pg           (pruning deletes the DB's data PVCs)
- ObjectStore/wp-pg-store (barman backup target)
- ScheduledBackup/wp-pg-daily
- ExternalSecret/hetzner-s3-creds (barman S3 creds)

Landing the annotation via the existing seed-woodpecker KS guarantees it is live
on the objects before any move. Metadata-only; no spec change, so CNPG/the
running wp-pg pod are untouched. The Cluster keeps the annotation permanently as
a data-guard; the others are incidental to the same handoff.

The woodpecker *app* objects (server/agent/Namespace/etc., currently under the
catch-all apps KS) are protected separately in the next stage — they need
per-object top-level annotations rather than commonAnnotations, which would
propagate into the Deployments' pod templates and needlessly restart live CI.

Co-Authored-By: Claude Bot <claude-bot@renner.uno>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

claude-bot added 1 commit 2026-07-25 03:59:40 +00:00

chore(woodpecker): also prune-guard the app objects via commonAnnotations

ci/woodpecker/pr/pr-review Pipeline was successful

Details

27d338f9be

Folds the app-object protection into stage 1 now that a woodpecker CI restart is
acceptable. commonAnnotations adds kustomize.toolkit.fluxcd.io/prune: disabled to
every object under apps/woodpecker/ (the woodpecker-ci Namespace, server/agent
Deployments, Service, Ingress, PDB, NetworkPolicy, ResourceQuota/LimitRange,
RBAC, ExternalSecret), so when 'woodpecker/' is later removed from
apps/kustomization.yaml the catch-all apps KS can't prune them mid-handoff.

Trade-off accepted: kustomize propagates commonAnnotations into the two
Deployments' pod templates, so this rolls woodpecker-server + agent once on
apply (and once more when removed in the final stage). Confirmed harmless — the
DB (wp-pg) is a separate CNPG resource, untouched.

Co-Authored-By: Claude Bot <claude-bot@renner.uno>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

review-bot reviewed

2026-07-25 04:06:08 +00:00

review-bot left a comment

🤖 Automated review — model claude-haiku-4-5-20251001 (complexity: trivial), commit 27d338f9bea617ad323f4c781a84bcd9c5b84a99.

Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.

Summary

This PR adds kustomize.toolkit.fluxcd.io/prune: disabled annotations to the woodpecker CNPG cluster and its supporting infrastructure objects, as stage 1 of a planned multi-stage migration from seed-woodpecker to a dedicated KS. The pattern is proven (successfully applied to InfluxDB per #388/#390), annotations are correctly placed, and documented safeguards are in place.

🟢 Verification

All changes verified:

Files: All 5 YAML files referenced in the diff exist and are correctly modified (kubernetes/apps/woodpecker/kustomization.yaml, cluster.yaml, three supporting seed objects).
Annotations: Applied to the right objects—CNPG Cluster (CRITICAL data guard), supporting DB infrastructure (ObjectStore, ScheduledBackup, ExternalSecret), and all 13 app objects via commonAnnotations (Deployments' pod templates included).
Pattern consistency: Identical annotation pattern already used in InfluxDB setup (kubernetes/apps/influxdb/helmrelease.yaml, externalsecret.yaml) and across the codebase (PVCs, snapshot objects, etc.). Proven approach.
Manual verification: PR author confirmed kubectl kustomize seed/woodpecker annotates 4 DB objects and apps/woodpecker annotates all 13 objects correctly. Barman backups (~70m) verified as a backstop.
YAML syntax: Valid; no malformed annotations or metadata.

Design notes

Trade-off documented: The commonAnnotations propagation into pod templates will roll woodpecker-server and agent Deployments on merge (and again on stage 3 removal). Author confirms this is acceptable with maintainer sign-off.
Transient annotation: Correctly scoped as temporary—to be removed in stage 3 once the new dedicated KS owns these objects. Documented in comments.
Data safety: The annotation on Cluster (which owns the PVCs) protects against accidental deletion during the ownership handoff. InfluxDB demonstrates this pattern works.

Recommendation

Looks reasonable — no blocking issues. This is careful, well-documented groundwork for a safe migration.

🤖 **Automated review** — model `claude-haiku-4-5-20251001` (complexity: trivial), commit `27d338f9bea617ad323f4c781a84bcd9c5b84a99`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary This PR adds `kustomize.toolkit.fluxcd.io/prune: disabled` annotations to the woodpecker CNPG cluster and its supporting infrastructure objects, as stage 1 of a planned multi-stage migration from `seed-woodpecker` to a dedicated KS. The pattern is proven (successfully applied to InfluxDB per #388/#390), annotations are correctly placed, and documented safeguards are in place. ## 🟢 Verification All changes verified: - **Files**: All 5 YAML files referenced in the diff exist and are correctly modified (`kubernetes/apps/woodpecker/kustomization.yaml`, `cluster.yaml`, three supporting seed objects). - **Annotations**: Applied to the right objects—CNPG Cluster (CRITICAL data guard), supporting DB infrastructure (ObjectStore, ScheduledBackup, ExternalSecret), and all 13 app objects via `commonAnnotations` (Deployments' pod templates included). - **Pattern consistency**: Identical annotation pattern already used in InfluxDB setup (`kubernetes/apps/influxdb/helmrelease.yaml`, `externalsecret.yaml`) and across the codebase (PVCs, snapshot objects, etc.). Proven approach. - **Manual verification**: PR author confirmed `kubectl kustomize seed/woodpecker` annotates 4 DB objects and `apps/woodpecker` annotates all 13 objects correctly. Barman backups (~70m) verified as a backstop. - **YAML syntax**: Valid; no malformed annotations or metadata. ## Design notes - **Trade-off documented**: The `commonAnnotations` propagation into pod templates will roll woodpecker-server and agent Deployments on merge (and again on stage 3 removal). Author confirms this is acceptable with maintainer sign-off. - **Transient annotation**: Correctly scoped as temporary—to be removed in stage 3 once the new dedicated KS owns these objects. Documented in comments. - **Data safety**: The annotation on Cluster (which owns the PVCs) protects against accidental deletion during the ownership handoff. InfluxDB demonstrates this pattern works. ## Recommendation Looks reasonable — no blocking issues. This is careful, well-documented groundwork for a safe migration.

k.renner merged commit 5d3f94fd8b into master

2026-07-25 04:12:21 +00:00

k.renner referenced this issue from a commit

2026-07-25 04:12:21 +00:00

Merge pull request 'chore(woodpecker): pre-stage prune:disabled on the wp-pg CNPG objects (stage 1)' (#394) from woodpecker-prune-protect into master

claude-bot referenced this issue from a commit

2026-07-25 04:18:55 +00:00

refactor(woodpecker): dedicated woodpecker KS, retire seed-woodpecker (stage 2)

claude-bot referenced this pull request

2026-07-25 04:19:12 +00:00

refactor(woodpecker): dedicated woodpecker KS, retire seed-woodpecker (stage 2) #396

Sign in to join this conversation.