Testkube is orphaned: README lists it as deployed, but no kustomization references it

[devantler]

🤖 Generated by the Daily AI Assistant

Problem

The testkube/ controller is present in the tree with a complete, deploy-ready setup — k8s/bases/infrastructure/controllers/testkube/ has helm-release.yaml (a real HelmRelease, infinite install/upgrade remediation), helm-repository.yaml, namespace.yaml, networkpolicy.yaml, and a full crds/ set — but nothing references it:

• k8s/bases/infrastructure/controllers/kustomization.yaml does not list testkube/ in its resources:.
• No provider overlay (k8s/providers/docker/..., k8s/providers/hetzner/...) references it either.
• Repo-wide, the only files mentioning testkube are inside the testkube/ dir itself.

So Flux never reconciles Testkube — it is effectively dead config.

Meanwhile, the README's "What you get" inventory advertises it as deployed:

- **Testing** — Testkube _(local/CI only; not deployed to prod)_

This is a doc-vs-reality drift: either the inventory over-claims, or a wiring step was dropped.

Proposed direction (maintainer decides intent)

Pick one:

1. Re-wire — if Testkube is meant to run on the local/CI overlay, add - testkube/ to k8s/bases/infrastructure/controllers/kustomization.yaml (it's not in the Hetzner overlay's individual base refs, so prod stays opted out, matching the README qualifier). Then validate kubectl kustomize + a local ksail reconcile.
2. Remove — if Testkube was intentionally dropped (e.g. to keep CI lean), delete k8s/bases/infrastructure/controllers/testkube/ and the - **Testing** — Testkube … README bullet so the inventory matches reality.

Size

Small. Option 1 is a one-line kustomization add + validation; option 2 is a dir + README-line removal.

Note

The devantler.tech docs-site inventory for platform-template was not carrying this stale Testkube row (it had simply not been synced at all), so it is unaffected by this — see the companion docs-sync PR adding the genuinely-deployed Virtualization (KubeVirt + CDI) row (devantler-tech/monorepo#1986). Whichever option is chosen here, the docs site already reflects the deployed set minus Testkube.

[devantler]

Decision-ready triage — wire-in vs remove

Dug into this against the live tree (and the authoritative devantler-tech/platform repo). Correcting my own original framing first: the README does not say Testkube is deployed — both this template and the prod platform say **Testing** — Testkube _(local/CI only; not deployed to prod)_. The real bug is narrower and sharper:

Testkube is wired into nothing. The k8s/bases/infrastructure/controllers/testkube/ dir is a complete, self-contained controller (HelmRelease + HelmRepository + namespace + NetworkPolicy + full CRD set + its own kustomization.yaml), but no kustomization references it — it's omitted from k8s/bases/infrastructure/controllers/kustomization.yaml, and neither provider overlay adds it. So it renders into zero clusters today.

That also means the README's "local/CI only" is currently false — the docker (local/CI) provider deploys the full base set, and the base set omits Testkube, so it runs nowhere.

The architecture points at a likely-intended fix

• The base controllers set is what the docker (local/CI) provider deploys in full (- ../../../../bases/infrastructure/controllers/).
• The hetzner (prod) overlay enumerates base controllers explicitly and opts out of unused ones (per its in-file comment) — it would not pick up a new base controller automatically.

So adding - testkube/ to k8s/bases/infrastructure/controllers/kustomization.yaml would deploy Testkube in docker/local-CI but not hetzner/prod — which exactly matches the README's "local/CI only; not deployed to prod" intent. That strongly suggests the - testkube/ line was simply forgotten when the manifests were authored.

Two defensible directions — your call

1. Wire it in (add - testkube/ to the base kustomization). Makes README ↔ manifests ↔ kustomization consistent. Cost: Testkube is a heavy stack (API server + operator + MinIO + NATS + mongo) — this adds real resource load and a flakiness surface to every consumer's local/CI clusters by default. Given prod recently opted out of kubevirt+cdi for memory, this deserves an explicit yes.
2. Remove the dir. Behavior-preserving (it renders nothing today, so kustomize output is byte-identical) and matches the prod platform, which carries zero Testkube GitOps manifests. Cleanest if in-cluster Testkube isn't actually wanted and "local/CI testing" means the Testkube CLI/agent, not an in-cluster controller.

Recommendation: lean toward (1) wire-in if you want Testkube available in template consumers' local/CI clusters; otherwise (2) remove. Happy to ship either as a draft the moment you pick — both are small.

🤖 Generated by the Daily AI Assistant

[devantler]

I decide to go with 1