helm-expt Test Map

This is the starting page for all helm-expt testing. It maps every test class across the four systems we exercise - Helm · Kubernetes · ConfigHub · cub - to where it lives and its honest coverage. The detailed strategy, command runbooks, runners, and UX surfaces are the layers beneath it (see The layers).

UNOFFICIAL/EXPERIMENTAL. Testing here means claims matched to evidence, not green-for-its-own-sake. The bar is verified disposition, not "everything green" (see How we state coverage).

The four systems we test

• Helm - does cub installer render the same object set as regular Helm, and what happens to Helm hooks?
• Kubernetes - do the rendered objects actually run on a cluster (local kind, and strict two-cluster parity)?
• ConfigHub - do the objects become Units, scan, upload via OCI, reconcile under Argo/Flux, and promote across variants?
• cub - do cub installer, cub variant, and cub-scout (day-1 preview) do what the catalog claims?

Test classes

The coverage matrix

Which system each class exercises, where it lives, and its honest coverage. Legend: ● exercises · ○ partial/indirect · – n/a. Counts are indicative - the authoritative live numbers are in the generated surface linked per row.

How we state coverage

This is the honesty rule that keeps the map trustworthy:

1. "Complete / 100%" applies only to the static catalog parity & verification - render parity and verified disposition. That part is genuinely finished (1194 frontier cells, 100% verified disposition, 0 genuine todo).
2. Every live / lifecycle / UX class states its own honest coverage - counts, watch/blocked, and what's pending - never rolled up into a blanket "100% of everything." watch ≠ pass; promotion-proven ≠ production-proven; render parity ≠ live-ready; a routed hook ≠ an executed hook.
3. Each number cites its generated surface (linked above), so the map stays honest and current instead of asserting. The live dashboard is status-dashboard; this page is the map.

The layers

The map routes into the existing detail - fit around this page, not replaced by it:

Test cadence

Use scoped checks while working. Use the full repository verifier (npm run verify) as a broad release gate after focused checks pass. Use live tests only to create or refresh live evidence.

Do not use npm run verify as a substitute for a fresh live test (it verifies the committed corpus and receipts). Do not use a live test as a substitute for render parity. They prove different things.

Cluster/runtime runners (resolve the repo from their own location)

• chart-install-test - install one chart/base via cub installer → ConfigHub → OCI → Argo on a cub-managed kind cluster; verify runtime + three-way agreement; emit a receipt.
• chart-install-sweep - shardable top-20 driver: --rig <cub-cluster-name> [--shard i/n] [--slugs a,b].
• live-helm-installer-kind-parity-test - strict two-cluster Helm-vs-installer parity without ConfigHub's cluster helper.
• live-helm-confighub-parity-test - live Helm vs ConfigHub delivery, dual compare.
• target-bound-derived-variant-test - cub variant create --target, publish the derived Space as OCI, deliver it through Argo, verify runtime, and emit a receipt.
• existing-secret-proof - the F3 fix path: pre-provision the Secret, install the existing-secret base, confirm Ready.
• Lifecycle proofs: npm run hook-test:proof / hook-execution:proof (and :verify) - route a hook as an explicit, receipted action on a throwaway kind cluster.

Run (standalone)

New to cub? Install the cub CLI first. You can pull and render public catalog packages without an account. Commands that save or change ConfigHub data require you to sign in.

cub auth login                      # verify: cub organization list (NOT cub info)
cub cluster up --name myrig
tests/chart-install-test --package packages/bitnami/nginx/24.0.2 --slug nginx \
  --namespace nginx --rig myrig --json     # add --helm-expt . if run from elsewhere
cub cluster down --name myrig