oleks/cms-plugins
1
0
Fork 0
Code Issues 3 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
67b07634ae88fb50014aa5c17aa08c7dbf4ea47a
cms-plugins/deploy/fleet-overlay/README.md
T
Oleks 67b07634ae initial scaffold: emdash catalog, helm chart, woodpecker pipeline, ddev 
- app/: Emdash scaffold (Astro 6, node target) with cmses/plugins/pages collections
- app/seed/seed.json: WordPress→Emdash parity for kotkanagrilli.fi (~30 entries)
- Dockerfile + docker/entrypoint.sh: multi-stage build, single PVC at /app/state
- deploy/helm/: chart mirroring emdash-kotkanagrilli (single-replica, sqlite, kotkan)
- deploy/fleet-overlay/: HelmRelease/source/image-automation templates for
  anton-helm-workloads (staging + production)
- .woodpecker/container.yaml: arm64 build, three OCI tags per push
  (immutable 0.1.<pipeline> + floating <branch> + <branch>-latest)
- .ddev/: local dev with nginx proxy to emdash on :4321
- README/DEPLOYMENT/ARCHITECTURE/CLAUDE: docs covering the three-repo
  pipeline (cms-plugins + anton-helm-workloads + Gitea OCI registry)
2026-05-20 11:19:00 +03:00

2.4 KiB
Raw Blame History

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 — two Secrets per env: the SSH deploy key Flux uses to clone this repo (cms-plugins-deploy-key, in flux-system), and the pod's env-var secret (cms-plugins-{staging,production}-secrets, in kotkan). 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.

Reference in New Issue View Git Blame Copy Permalink