Background
Helm's --post-renderer flag runs an external binary that receives rendered YAML on stdin and outputs modified YAML on stdout. Typical use cases: kustomize patches, sealed-secrets transforms, security policy injection.
Helm SDK exposes this via the postrender.PostRenderer interface, and ships postrender.NewExec(binaryPath, args...) (upstream) — exactly the CLI behavior.
Scope — external binary only
A Java-callback PostRenderer (where Java code transforms the YAML in-process) requires JNA callbacks back into Java from Go and is out of scope for this issue. Stick to the exec-binary path that matches helm CLI's --post-renderer. If the callback path is wanted later, file a separate issue.
Acceptance criteria
Proposed Java API
helm.template()
.withPostRenderer(Paths.get("/usr/local/bin/my-transform.sh"), "--arg1", "--arg2")
.call();
Implementation guide
Go (native/internal/helm/install.go, upgrade.go, template.go)
- Add
PostRenderer string (binary path) and PostRendererArgs []string to each options struct.
- When
PostRenderer != "":
pr, err := postrender.NewExec(options.PostRenderer, options.PostRendererArgs...)
if err != nil { return "", err }
client.PostRenderer = pr
CGO bridge (native/main.go)
- Add
char* postRenderer; and char* postRendererArgs; to the install/upgrade/template structs.
- For args: pass as a single string with a separator (e.g.
\n); split Go-side. Avoid , since arg values may legitimately contain it.
JNA + Java
- Add
public String postRenderer; and public String postRendererArgs; to each *Options.java. Update @Structure.FieldOrder and constructors.
- Add
withPostRenderer(Path binary, String... args) to the three commands. Join args with the same separator the Go side splits on.
Tests
- Add to
HelmInstallTest, HelmUpgradeTest, HelmTemplateTest.
- Use
@TempDir to write a tiny test renderer script per test. Skip on Windows (@DisabledOnOs(OS.WINDOWS)) — no POSIX shell.
- Sample renderer:
#!/bin/sh
sed 's/replicas: 1/replicas: 99/g'
- After running with the post-renderer set, assert the rendered output contains
replicas: 99.
- Also cover: missing binary path → exception with a clear message.
Contributor checklist
References
Background
Helm's
--post-rendererflag runs an external binary that receives rendered YAML on stdin and outputs modified YAML on stdout. Typical use cases: kustomize patches, sealed-secrets transforms, security policy injection.Helm SDK exposes this via the
postrender.PostRendererinterface, and shipspostrender.NewExec(binaryPath, args...)(upstream) — exactly the CLI behavior.Scope — external binary only
A Java-callback PostRenderer (where Java code transforms the YAML in-process) requires JNA callbacks back into Java from Go and is out of scope for this issue. Stick to the exec-binary path that matches helm CLI's
--post-renderer. If the callback path is wanted later, file a separate issue.Acceptance criteria
withPostRenderer(Path binary, String... args)onInstallCommand,UpgradeCommand, andTemplateCommandProposed Java API
Implementation guide
Go (
native/internal/helm/install.go,upgrade.go,template.go)PostRenderer string(binary path) andPostRendererArgs []stringto each options struct.PostRenderer != "":CGO bridge (
native/main.go)char* postRenderer;andchar* postRendererArgs;to the install/upgrade/template structs.\n); split Go-side. Avoid,since arg values may legitimately contain it.JNA + Java
public String postRenderer;andpublic String postRendererArgs;to each*Options.java. Update@Structure.FieldOrderand constructors.withPostRenderer(Path binary, String... args)to the three commands. Join args with the same separator the Go side splits on.Tests
HelmInstallTest,HelmUpgradeTest,HelmTemplateTest.@TempDirto write a tiny test renderer script per test. Skip on Windows (@DisabledOnOs(OS.WINDOWS)) — no POSIX shell.replicas: 99.Contributor checklist
@authorJavadoc tagmake build-native && ./mvnw test -pl helm-javagreenReferences
--post-renderer)