Review a Helm values change by reading the rendered output, not only the YAML diff. Check which images, registries, ports, permissions and enabled features changed, confirm who owns the values file, and make sure a reviewer other than the author approved it. A one-line values edit can change many manifests.
Why values files deserve a real review
A values file looks like configuration, so reviewers skim it. But in Helm, values are inputs that decide what the templates produce. A change to image.repository, service.type or rbac.create can alter what runs in your cluster and who can reach it.
Helm merges values from several places. According to the Helm documentation, the chart's own values.yaml is the default, a parent chart can override a subchart, a file passed with -f overrides those, and values set on the command line win over everything. So the file in the pull request is only one layer of the final result.
A five step routine
- Render before and after. Run
helm templateon the base branch and on the pull request branch with the same chart version and the same values files, then diff the two outputs. Reviewing the diff of rendered manifests shows effects the values diff hides. - Look at image fields first. Did a registry, repository, tag or digest change? A new registry host is a new trust decision. A move from a pinned digest to a floating tag is a regression.
- Look at exposure. Service type, ingress hosts, annotations, host ports and network settings. Anything that makes a workload reachable from outside the cluster deserves a named approver.
- Look at permissions. Service account names, RBAC creation flags, security context settings and anything that adds capabilities or runs as root.
- Look at what was removed. Deleting a key can silently restore a chart default. The Helm docs note that setting a key to null removes the default for it, so a null in a values file is a deliberate change worth a question.
Here is a small example of a diff that deserves a comment.
image:
repository: registry.example.com/team/api
tag: "1.8.2"
service:
type: LoadBalancer
The tag bump is routine. The service type change is not, and the reviewer should ask who needs that exposure.
What to ask the author
- Which environment does this file apply to?
- Is the chart version unchanged? If the chart version moved in the same pull request, review the chart change separately.
- Were new keys checked against the chart's documented values, or copied from a forum answer?
- Is there a schema? A
values.schema.jsonfile lets Helm reject bad types and unknown shapes on install, upgrade, lint and template, per the Helm chart documentation.
Make the routine cheap
Reviewers skip steps that take twenty minutes. Put the render and diff in CI and post the result as a comment on the pull request. Add a required reviewer for the values directory so the right people see the change. Keep one values file per environment so a production change is never hidden inside a shared file.
Try it yourself
Click through it at your own pace, or open it full screen.
The demo shows a pull request being held until a policy check passes. Watch how the merge stays blocked until the failing condition is resolved, which is the same idea as a required review on a values change. Safeguard policies and gates work on the software and dependency side of that pull request. Reviewing the manifests themselves remains a human and process step.
Quick check
Is the values diff enough?
No. The rendered manifests show the real effect, including defaults that moved and templates that react to a changed value.
Who should approve a values change?
At minimum someone who did not write it. For image, exposure or permission changes, the owner of the workload or the platform team should also approve.
Sources
Last reviewed: 19 October 2026.
