oleks/cms-plugins

Fork 0

Files

T

History

Oleks bdc43bb1d6

ci/woodpecker/push/container Pipeline was successful

Details

fix(deploy): align fleet-overlay blueprint with the live kotkan deploy

The deploy/fleet-overlay templates had drifted from what actually runs in
anton-helm-workloads (verified live + against the emdash-kotkanagrilli
reference). Canonical design co-locates everything in the `kotkan` namespace:

- source.yaml: GitRepository flux-system -> kotkan, so the HelmRelease
  chart sourceRef resolves same-namespace (no cross-namespace ref).
- secrets.yaml: deploy-key Secret -> kotkan, defined once in the staging
  overlay; dropped the duplicate definition from the production overlay
  (production references the shared key by name).
- image-automation.yaml: IUA write-back sourceRef
  anton-workloads-image-automation/flux-system -> anton-helm-workloads/kotkan
  (the existing read source already has push access).
- README.md / DEPLOYMENT.md: namespace + ownership docs corrected.

2026-06-02 03:24:52 +03:00

cms-plugins-production

fix(deploy): align fleet-overlay blueprint with the live kotkan deploy

2026-06-02 03:24:52 +03:00

cms-plugins-staging

fix(deploy): align fleet-overlay blueprint with the live kotkan deploy

2026-06-02 03:24:52 +03:00

README.md

fix(deploy): align fleet-overlay blueprint with the live kotkan deploy

2026-06-02 03:24:52 +03:00

README.md

Fleet overlay templates

The YAMLs under cms-plugins-staging/ and cms-plugins-production/ are the FluxCD manifests that drive each environment. They are not consumed from this repo — they live here as a versioned blueprint, intended to be copied into the workloads repo that Flux watches:

git.oleks.space/anton/helm-workloads
  ├─ cms-plugins-staging/        ← copy from deploy/fleet-overlay/cms-plugins-staging/
  ├─ cms-plugins-production/     ← copy from deploy/fleet-overlay/cms-plugins-production/
  └─ kustomization.yaml          ← add both directories to `resources:`

See ../../DEPLOYMENT.md for the full pipeline and the first-time setup checklist (deploy keys, sops secrets, Woodpecker secrets, DNS).

Shape

Each env directory contains five files, mirroring the emdash-kotkanagrilli layout in ~/projects/servers/fleet/apps/base/:

source.yaml — GitRepository pointing at this repo on the matching branch (staging / production), restricted to /deploy/helm via the ignore rule so Flux only pulls the chart.
helmrelease.yaml — HelmRelease consuming the chart from ./deploy/helm in that GitRepository. Pinned by digest (see image-automation.yaml).
image-automation.yaml — ImageRepository + ImagePolicy + ImageUpdateAutomation. Watches the floating staging / production tag in the Gitea OCI registry, resolves the current digest, and rewrites the digest setter in helmrelease.yaml (which is what actually makes helm upgrade see a change when CI retags the image).
secrets.yaml — the pod's env-var secret (cms-plugins-{staging,production}-secrets, in kotkan). The staging overlay's secrets.yaml additionally defines the shared SSH deploy key (cms-plugins-deploy-key, also in kotkan so the GitRepository secretRef resolves same-namespace); production references that same key by name and does NOT redefine it. Templates here are NOT encrypted — sops-encrypt them before pushing to anton-helm-workloads.
kustomization.yaml — bundles the above.

Why this lives in two repos

The chart (deploy/helm/) ships with the app — that way a chart change is reviewed and tagged alongside the code that depends on it. The HelmRelease references the chart as a path inside a GitRepository, not as an OCI artifact, so there's no "publish chart" step in CI.

The HelmRelease itself lives in the workloads repo because that repo is the source of truth for what runs on the kotkanagrilli.fi subdomain pool. Same convention as the existing kotkanagrilli/ (legacy WP) and hello-kotkan/ entries there.