Repository navigation
Testkube CRDs are installed twice: by the chart and by vendored copies #263
Description
🤖 Generated by the Agentic Engineer (interactive Claude Code session)
Evidence
Found by the raw-manifest sweep on #205, against main at 679fe8b (2026-10-24):
k8s/bases/infrastructure/controllers/testkube/custom-resource-definitions/vendors 13 Testkube CRDs, and the same directory'sHelmReleaseinstalls the Testkube chart, whose operator subchart installs those CRDs by default (testkube-operator.installCRD: truein the upstream values).- The vendored copies carry Helm's own ownership annotations (
meta.helm.sh/release-name: testkube), so they look like a dump of an earlier chart install. - Nothing in the template uses a Testkube custom resource, so the copies give validation nothing either.
Audience and problem
Operators of platforms built from this template. Two owners apply the same CRDs: the chart moves them on every chart upgrade, and Flux re-applies the frozen copies, so the CRDs can drift back to an older schema after an upgrade, and the copies have to be refreshed by hand.
Smallest useful change
Confirm why the copies were added (history before this clone's depth). If nothing depends on them, remove them and let the chart own the CRDs; if something does, record that reason next to them.
Acceptance criteria
- Exactly one owner installs the Testkube CRDs, or the copies carry the reason they must stay.
- Both provider renders and both
ksail workload validateruns stay green.
Size
XS.
Activity
devantler commentedon Oct 25, 2026
Refined (2026-10-25): removing the copies in one step is not safe for existing platforms. Kept open, not implemented.
What I checked, against
mainat679fe8b:39ac525), copied from the reference platform. The platform later removed its whole Testkube tree as dead weight (chore(infrastructure): remove dead Testkube manifests platform#2013); no commit here records a reason to keep the copies.helm templateof the pinned chart (2.9.5) renders 15 Testkube CRDs from its operator subchart's templates, while the template vendors only 13, so the chart is already the only source of two of them. The chart's one custom resource is a post-install/post-upgrade hook, so it never needs the CRDs before the release itself creates them.infrastructure-controllersFlux Kustomization runs withprune: true. Deleting the files makes Flux garbage-collect the live CRDs on every platform already running the template, and Kubernetes then deletes every Testkube resource of those kinds (tests, workflows, execution history) before Helm's drift correction recreates the empty CRDs. Flux skips a prune only when the live object carrieskustomize.toolkit.fluxcd.io/prune: disabled, so the annotation has to reach clusters before the files go.Proposed delivery, in two template releases:
kustomize.toolkit.fluxcd.io/prune: disabledto the 13 vendored CRDs, so Flux stops being able to delete them.A platform that takes both template-sync updates in one jump still gets the prune. So step 2 needs either a waiting period recorded on this issue, or a note in the sync pull request telling owners who use Testkube to apply step 1 first. A separate question, not decided here: whether the template should keep Testkube at all now that the reference platform has dropped it.
Acceptance criteria are unchanged.
chore: agent-claim #263 nonce=4c809d0608c8a83736b14b5d3d9ab87b
devantler commentedon Oct 28, 2026
The removal needs a staged ownership handoff that preserves existing user data. Keep this issue open until that migration has passed its normal validation and adoption checks. No deletion was performed; this investigation is not counted as a completed resolution.
devantler commentedon Nov 3, 2026
Rechecked against current
maina54b1461e6fbbfd57835c06bb79d5dc3dd37ec3c: the HelmRelease now pins Testkube 2.14.2 with empty values, while the template still vendors 13 CRDs.The current chart defaults
testkube-operator.enabledto false, but that does not eliminate the duplicate owner. An actual client-sidehelm template --include-crdsof the exact pinned chart rendered 85 resources, including 15 CRDs. This was static chart rendering; no cluster was contacted or changed.The issue remains relevant. Keep the staged ownership handoff and existing data-preservation requirements; neither the chart bump nor the disabled operator justifies directly deleting the vendored CRDs.
chore: agent-claim #263 nonce=d57fc5ae08cbe5bb69ad2b04d26aef83
fix(testkube): stop Flux pruning the vendored CRDs before they are re…
devantler commentedon Nov 4, 2026
Step 1 of the staged handoff is merged. #365 (merged as 7a6592f) adds
kustomize.toolkit.fluxcd.io/prune: disabledto all 13 vendored Testkube CRDs through an inline patch in theirkustomization.yaml; the vendored files are unchanged and both KSail validations pass. The template itself publishes no releases (its release workflow skips this repository); instances receive the change frommainthrough their weekly template-sync PR.Remaining here (step 2): remove the vendored copies and their naming-gate exemptions so the chart is the only owner. Do it only once instances have had time to take this change; two weekly sync cycles puts the earliest review at 2026-11-17. The step-2 sync PR should still tell owners who use Testkube to merge the sync carrying this change first, because an instance that takes both in one sync would get the prune.
🤖 Generated with Claude Code