Skip to content
In this Guide

In this Guide

Deep Dives

AI: Claude and Codex patterns

ConfigHub: Deploy and manage

Journey 1 of 5

Helm ignores my values

Helm accepts a values file without checking it against the chart. When an assistant writes values from memory, some of them are for a different chart, and they do nothing. The install still succeeds. One command tells you which values those are.

Time. About five minutes. Needs. cub, the workshop plugin and helm. No server, no account, no cluster.

Run it yourself

The journey is a folder in the public workshop-demo repository. Its script pauses before each command, and Enter runs it. Read each command before continuing; stop with Ctrl+C whenever you have the result you need. ConfigHub sign-in, upload and protected-update steps are optional later work, not prerequisites for the local check.

# get the journeys
$ git clone https://github.com/monadic/workshop-demo

# use the version this page describes
$ git -C workshop-demo checkout --quiet 0e91722fb417

# open this journey
$ cd workshop-demo/1-catch-the-ai

# walk the steps, one command at a time
$ ./run.sh

Or let your agent run it

Give your agent the journey's PROMPT.md and nothing else. It follows the same steps, with the same numbers, and shows you the command after each one. You decide at each step whether to go on.

Keep this page and the README from your agent. They say what each step finds, so an agent that reads them knows the answers before it starts.

The steps

These are the steps in the journey's README. Run them from the journey's folder. The output of a real run is in expected/.

# the steps write their output here
$ mkdir -p work

1. Read what the assistant wrote

cat values.yaml. Nothing looks wrong.

2. Let Helm render it, and see what it would install

New to cub? Install the cub CLI first. Public catalog packages pull and render anonymously, and you sign in only once a command saves or changes ConfigHub data.

$ mkdir -p work

$ helm template shop-redis oci://registry-1.docker.io/cloudpirates/redis --version 0.34.11 --namespace shop -f values.yaml > work/redis.yaml

$ cub config check work/redis.yaml

Helm exits 0 and the objects look healthy. This is the trap.

3. Ask which of those values did anything

$ cub config values oci://registry-1.docker.io/cloudpirates/redis --version 0.34.11 --release shop-redis --namespace shop --values values.yaml

Look for 3 of 7 values did nothing. The disk size, the memory limit and the replica count are all IGNORED, because this chart has no master or replica section. For each one the report says where this chart does read that setting.

--release shop-redis --namespace shop gives the objects the same names as the step 2 render, such as StatefulSet shop-redis. Without them the report still counts the same values, but it names the objects release-redis.

4. Put each setting where this chart reads it

diff values.yaml values-fixed.yaml shows the three settings moved. One of them also changes its number. The assistant wrote replicaCount: 2 in another chart's meaning, two replicas beside a master. This chart counts every pod, so two replicas is replicaCount: 3. The right place is not enough when the same word means something else.

5. Ask again

Run the step 3 command on the corrected file.

$ cub config values oci://registry-1.docker.io/cloudpirates/redis --version 0.34.11 --release shop-redis --namespace shop --values values-fixed.yaml

It ends with Every value you set changed the result or matches the default. The replica count reads DEFAULT, because three pods is what this chart does anyway.

6. See what the fix changes in the objects

$ helm template shop-redis oci://registry-1.docker.io/cloudpirates/redis --version 0.34.11 --namespace shop -f values-fixed.yaml > work/redis-fixed.yaml

$ cub config diff work/redis.yaml work/redis-fixed.yaml

Look at what you were really getting. You asked for a 1Gi disk and had 8Gi. You asked for a memory limit and had none. Your two replicas were there, and only because the chart's default happens to be three pods. Nothing you wrote put them there.

7. Make it a gate

This is the step 3 command with --exit-code added, and it fails a build when a value did nothing.

$ cub config values oci://registry-1.docker.io/cloudpirates/redis --version 0.34.11 --release shop-redis --namespace shop --values values.yaml --exit-code

It exits 1 here, because three values did nothing. It also exits 1 when a value was NOT CHECKED because the chart needed more renders than --max-renders allows. It exits 0 when every value changed the result or matches the default, as values-fixed.yaml does. It exits 2 when the check could not run, for example because the chart could not be fetched, so a build can tell a real finding from a broken check.

Use it on your own configuration

The README's section Continue with your own chart runs the same check on your own files. This is its first command, and the section goes on from there. Replace each value in angle brackets with your own.

$ mkdir own-chart-review && cd own-chart-review

$ cp "<absolute-path-to-your-private-values-file>" values.yaml

$ cub config values "<your-chart-or-absolute-local-chart-path>" --version "<your-existing-version>" \
  --namespace "<your-existing-namespace>" --release "<your-existing-release>" \
  --values values.yaml --out diagnosis.json --render-out candidate.yaml --exit-code

The candidate is the explicit, flattened configuration the chart rendered from those inputs. Exit 1 means some values had no effect or were not checked; investigate before accepting. Exit 2 means the command could not complete; resolve that error before drawing conclusions about the values. Keep values.yaml and candidate.yaml private: the candidate can contain Secrets. The diagnosis keeps requested inputs and hashes; the candidate is the exact render to inspect next time. If settings need repair, change a copied values file and repeat the command in a new directory such as own-chart-review-fixed; do not leave only a failed candidate.

These Guides go further: Find why a Helm value did not change the output · Why did Helm ignore my values? · Answer the ten questions Helm users ask.

Why it happens

How configuration works explains it.

How the check knows

The chart is rendered with your values, then once more for each value with that one value taken out. If the objects are the same either way, the value did nothing. Charts generate passwords and checksums, so the fields that move between two renders of the same input are found first and left out of every comparison. No value is ever printed.

Where it continues

Configs. The next journey is AI overwrites my fixes.