Test with Helm directly

helm repo add cnpg https://cloudnative-pg.github.io/charts helm install cnpg cnpg/cloudnative-pg -n cnpg-system —create-namespace

Once happy, remove it

helm uninstall cnpg -n cnpg-system

From what I understand, the correct approach to using Helm charts via Flarks declaratively is to simply write it yourself.

The workflow is to first declare the helm chart, add commit, push, push the changes, wait for flux to reconcile.

---
apiVersion: v1
kind: Namespace
metadata:
  name: cnpg-system
---
apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
  name: cnpg
  namespace: flux-system
spec:
  interval: 10m
  url: https://cloudnative-pg.github.io/charts
---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: cnpg
  namespace: cnpg-system
spec:
  interval: 10m
  chart:
    spec:
      chart: cloudnative-pg
      version: ">=0.27.0 <1.0.0"
      sourceRef:
        kind: HelmRepository
        name: cnpg
        namespace: flux-system
      interval: 10m
  install:
    createNamespace: true
    remediation:
      retries: 3
  upgrade:
    remediation:
      retries: 3

initially (no CRD yet), but Flux retries on its reconciliation interval and it’ll succeed once the operator finishes installing. The only risk is a brief error state in the logs — functionally it works fine.

Want to add a CNPG Cluster resource now?

! flux reconcile kustomization infrastructure -n flux-system
⎿ ✗ kustomizations.kustomize.toolkit.fluxcd.io “infrastructure” not found

❯ What is the correct command to trigger an immediate reconciliation?

● The Flux kustomization is named flux-system (from your gotk-sync.yaml):

flux reconcile kustomization flux-system -n flux-system

❯ Do I need to push first or will it look at the local git repository?

● You need to push first. Flux runs inside the cluster and pulls from the remote Git repository (your ssh://git@github.com/RyanGreenup/kubernetes-template in gotk-sync.yaml). It has no access to your
local working copy.

❯ But then I need to commit and push changes that I don’t know necessarily work. And it seems like
cutting branches and pointing at other branches and so forth seems quite complicated. Is this the
typical workflow or would I typically iterate with Helm install and then Helm uninstall?

● Good question. Both approaches are used — it depends on the stage of work.

Typical workflow

Iterate locally first, commit when it works:

Install and test

helm repo add cnpg https://cloudnative-pg.github.io/charts
helm install cnpg cnpg/cloudnative-pg -n cnpg-system —create-namespace

Verify it works

kubectl get pods -n cnpg-system

Happy? Tear it down, commit the Flux manifests, push

helm uninstall cnpg -n cnpg-system
git add && git commit && git push

Let Flux take over

flux reconcile kustomization flux-system -n flux-system

This is the normal pattern. You wouldn’t blindly push Helm charts you’ve never tested. Flux is for
maintaining desired state, not for exploratory work.

When to use branches

Branches are mainly useful for:

Teams where changes go through PR review
Staging clusters that track a staging branch

For a single-person dev cluster, just iterate locally with helm install/helm uninstall, then commit to main once you’re happy. No need for feature branches.

The mental model

helm install = “let me try this”
Flux HelmRelease = “this is what I want running permanently”

Drift correction means Flux will revert any manual helm install that conflicts with what’s in Git,
so pause Flux if you’re experimenting on something it already manages:

flux suspend kustomization flux-system

… experiment …

flux resume kustomization flux-system

────────────────────────────────────────────────────────────────────────────────────────────────────── ❯ Now, let’s implement the logic to pull newer images and newer helm charts.
────────────────────────────────────────────────────────────────────────────────────────────────────── ⏵⏵ bypass permissions on (shift+ta… ✗ Auto-update failed · Try claude doctor or npm i -g @anthro…