helm parse error in multiple templates: unclosed action

[Eykha]

What steps did you take and what happened:
Install the chart via helm.

What did you expect to happen:
Installs successfully.

Anything else you would like to add:
Looks like extra line breaks were added at the end of multiple helm value references in #4635.
See charts/gatekeeper/templates/gatekeeper-controller-manager-deployment.yaml:71 for example. Link

Environment:

• Gatekeeper version: v3.23.1
• Kubernetes version: (use kubectl version): v1.36.3

[shashankvarma499]

I'd like to work on this.

[shashankvarma499]

@Eykha @JaydipGabani looked into this and there are two things I want to check before the fix settles.

I can see the 12 folded actions: 6 in charts/gatekeeper/templates/gatekeeper-controller-manager-deployment.yaml and 6 in the audit deployment, the --admission-events-involved-namespace={{ .Values... }} style where the closing }} landed on the next line.

1. config/ is clean, and the fold shows up in manifest_staging/charts/gatekeeper/templates, which is what make manifests produces from config/ through kustomize and helmify. charts/ is then overwritten from manifest_staging/charts by the promote-staging-manifest target. So patching charts/ on its own gets undone the next time a release runs that target. My read is the fix has to land in the generation step, or in the source so the encoder does not fold there. Which is the intended place for it?

2. With current Helm the folded action parses and renders fine. I tried 3.16.4 and 4.2.3, and helm lint passes on the unpatched chart in both. The unclosed action error looks like it needs a pre-Go 1.16 template lexer. Which Helm version did you hit the failure on? That tells us whether this is a real break on supported versions or a formatting cleanup.

[Eykha]

@shashankvarma499

1. Not sure.
2. I'm using Argo CD v3.4.4 which bundles Helm v3.19.4.

I can also confirm that on helm 4.2.3 the chart passes linting. Imo even if recent versions of helm seem to handle this fine, it should still be fixed as this syntax is very unusual.

[shashankvarma499]

@Eykha thanks, that answers both open questions well enough to close the loop.

2. Which Helm version. It is not 3.19.4. I bisected the chart across Helm releases and it parses on every version from 3.6.3 onward. The failure only reproduces on the template lexer that shipped before Go 1.16, which is Helm 3.5 and older:

helm	go	chart
3.4.2	go1.14.13	FAIL: parse error at (gatekeeper/templates/gatekeeper-controller-manager-deployment.yaml:71): unclosed action
3.6.3	go1.16.5	ok
3.9.4	go1.17.13	ok
3.16.4	go1.22.7	ok
3.19.4	go1.24.11	ok

Same class as cybozu-go/moco#396, which was closed because helm 3.7+ stopped failing. So Argo CD v3.4.4 is probably not rendering with a stock Helm 3.19.4: if the repo-server shells out to a helm binary on PATH, or bundles an older one, you would get exactly this error. A helm version inside the repo-server would confirm which.

1. Where the fix belongs. You called it, and it is the generation step. The breaks are not in the source. cmd/build/helmify/kustomize-for-helm.yaml keeps every action on one line. They come from the kustomize build, whose YAML emitter wraps long plain scalars at around eighty columns and breaks at the space before the closing braces. helmify copies that through verbatim into manifest_staging/charts, and promote-staging-manifest then copies it to charts, so a hand edit to charts/ is undone by the next release.

PR #4824 now normalises the stream inside helmify right before each object is written, so every generation comes out clean, and it regenerates both manifest_staging/charts and charts. It also moves the helmify invocation to the package form (go run ./cmd/build/helmify) so it keeps working with the new test file, and adds a unit test for the normalisation.

Verified: helm 3.4.2 lints the chart clean now, and the rendered manifests are byte-identical to before, so no behaviour changes.

One unrelated thing I hit while regenerating: charts/ on master is currently behind manifest_staging, for example it is missing the enableAdmissionViolationExport args and the defaultK8sNativeValidationFailurePolicy flag. I left that alone as it is outside this issue.