Verify It Yourself

UNOFFICIAL/EXPERIMENTAL

You do not need to trust a screenshot or a README claim. The repo is built so a reader can rerun checks and inspect receipts.

Check The Offline Corpus

These checks do not need a cluster or network:

npm run site:verify
npm run docs:verify
npm run data:index:verify

For a broader release gate, run:

npm run verify

That command is intentionally larger. Use it before publishing or reviewing a large change, not after every small edit.

Check A Rendered Install

For Redis, render a catalog base and verify that your rendered output matches the catalog acceptance contract:

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.

What this command does. cub installer is a released, open-source plugin for the cub CLI. cub installer setup pulls a catalog package and writes its Kubernetes files locally. It does not apply those files to a cluster; use kubectl, Argo CD, or Flux for delivery. The generated scripts stop before doing any work when the plugin or kustomize is missing.

cub installer setup \
  --pull oci://europe-west1-docker.pkg.dev/nth-fort-499605-q5/helm-expt/bitnami-redis:25.5.3 \
  --base default \
  --work-dir .tmp/demo/redis-default \
  --non-interactive \
  --namespace redis

npm run redis:verify-install:render -- \
  --base default \
  --work-dir .tmp/demo/redis-default \
  --namespace redis

Expected result:

PASS redis:verify-install:render bitnami/redis/25.5.3 default

Rerun A Two-Cluster Parity Check

Use this when you want to compare regular Helm in one vanilla kind cluster with cub installer output in another:

npm run kind-parity:run -- \
  --chart bitnami/redis \
  --version 25.5.3 \
  --base default

Then verify the committed receipts:

npm run kind-parity:verify

The current generated report is:

Two-Cluster Kind Parity

Run these jobs serially. The parity harness creates and removes kind clusters owned by the run.

Rerun A ConfigHub/OCI Live Parity Check

Use this when you want the stricter live path: regular Helm, direct cub installer apply, and ConfigHub OCI/Argo delivery for the same committed recipe/base.

npm run live-parity:run -- \
  --recipe recipes/external-dns/external-dns/1.21.1 \
  --base no-crds

Then regenerate and verify the summary:

npm run live-parity:top20:summary
npm run live-parity:verify
npm run outcomes:generate
npm run status:dashboard

Run this lane serially. It creates kind clusters and uses the live ConfigHub and OCI path.

Validate A cub-scout Receipt

When you have a cub-scout receipt file, validate its fingerprint:

cub-scout receipt validate <receipt.json>

To create fresh live receipts against a cluster, use receipt verify with the predicate that matches the question:

cub-scout receipt verify \
  --file <rendered-objects.yaml> \
  --scope namespace/<namespace> \
  --predicate object-set-matches \
  --ttl 1h \
  --out .tmp/object-set.receipt.json

Useful predicates for installs are:

Use the cub-scout example for a self-contained runtime test:

confighub/cub-scout examples/helm-expt

Read The Claim Before Trusting It

Every status row has a scope. Check the chart, version, base, lane, and target profile before quoting it.

Start with:

• Current Proof Status
• Live Parity
• What We Refuse To Claim