Two of the Five Commands Suggested for Testing lookup Do Not Render Templates: How a Helm Docs PR Was Merged in 15 Hours and 54 Minutes

Result: Merged (2026-10-17 16:45, helm/helm-www#2307), confirmed to be reflected in the helm.sh documentation on the same day. In fact, this was taken from GitHub PR/review/check/timeline logs, the helm-www source (the PR's base commit faf08ad0), the Helm source (tags v3.22.1 and v4.3.1), and the draft contribution ledger. All times are in Korea Standard Time.

Table of Contents

• One-Line Summary
• 1. What Was the Problem: The Sentence We Saw
• 2. Cause: Which Line of the Source
  • Documentation Side
  • lookup Only Lives Inside the Rendering Engine
  • rollback and uninstall Do Not Take That Path
• 3. What Was Changed: Summary of the Diff
• 4. Response: Approval in 1 Hour 19 Minutes, Merge in 15 Hours 54 Minutes
• 5. Lessons Learned: Open Source Contribution Tips
• Links

One-Line Summary

1. What Was the Problem: The Sentence We Saw

Let's be honest first. This time, nothing was broken in TT Lab. We didn't get stuck following the documentation, but rather noticed while reading the documentation that a sentence did not match the source. The contribution ledger does not specifically record how this sentence was found. However, this draft was prepared in the same batch as the Grafana chart PR in Part 2, using the same Helm version (v3.18.2). As seen in Part 2, the random password for that chart relies on lookup , and in tools like Argo CD that render with helm template , lookup returns nothing. It appears we encountered this while reading the lookup section of the Helm documentation to verify that behavior.

Helm 공식 문서 「Template Functions and Pipelines」 의 lookup At the end of the section, there was the following paragraph (identical in the current docs and Helm 3 docs).

To test lookup against a running cluster, helm template|install|upgrade|delete|rollback --dry-run=server should be used instead

This is a sentence grouping five commands with | to be written all at once. Such lists cannot be known to be correct until tried out one by one. When actually run, the fourth and fifth ones differ.

The test chart simply draws (lookup "v1" "Namespace" "" "kube-system").metadata.name in a single template, and the cluster is a small cluster in TT Lab. The top three lines confirm that the first part of the sentence (template only looks at the cluster when it is =server ) is correct, and the last line is evidence that the second part of the sentence is incorrect. These values are exactly as written in the PR body, and the original output files were not preserved separately (the draft is in the contribution ledger). helm uninstall --dry-run=server was not tested and was verified solely through the flag definitions in the source (Section 2).

2. Cause: Which Line of the Source

Document line numbers are based on the PR's base commit faf08ad0 , and the Helm source is based on the latest Helm 3 release tag v3.22.1 at the time of writing the PR.

Documentation Side

• Current docs docs/chart_template_guide/functions_and_pipelines.mdx lines 271–274
• Helm 3 판 문서 versioned_docs/version-3/chart_template_guide/functions_and_pipelines.md lines 246–249

In both places, the same five commands were listed both as commands that do not attach to the API server when --dry-run , and as commands to test --dry-run=server with lookup .

lookup Only Lives Inside the Rendering Engine

• The engine has a placeholder for lookup . pkg/engine/funcs.go lines 67–71 The default lookup returns an empty map. The nil pointer in the first two lines of Section 1 occurred while trying to retrieve .metadata.name from this empty map.
• The real lookup is injected only when cluster connection information is provided to the engine(pkg/engine/engine.go lines 235–237). Whether to provide that connection information is determined by pkg/action/action.go lines 128–142 where renderResources sets it to interactWithRemote , and the comment also states 「helm template should not talk to a remote cluster, and --dry-run if this is false·none·server , try connecting」.
• install is pkg/action/install.go lines 256–258, and upgrade sets this value in pkg/action/upgrade.go lines 271–273 and calls renderResources . helm template runs the install action as a dry-run (cmd/helm/template.go lines 53, 86–92), so it follows the same path.

rollback and uninstall do not follow that path.

• rollback does not render the chart again; it directly retrieves the manifests stored in the target revision. pkg/action/rollback.go line 156 's Manifest: previousRelease.Manifest , and this file contains no renderResources calls.
• uninstall splits the stored release manifests to create a list of resources to delete (pkg/action/uninstall.go line 214).
• ). The flag shapes are also different. install's --dry-run is a string flag, and when used without a value, it becomes client (cmd/helm/install.go lines 183–184). rollback(cmd/helm/rollback.go line 79) and uninstall(cmd/helm/uninstall.go line 75) are BoolVar , so they try to read =server as a boolean, causing the ParseBool error from Section 1.

Helm 4 도 확인했습니다. v4.3.1 의 uninstall 은 여전히 참/거짓 플래그입니다(pkg/cmd/uninstall.go line 78). Although rollback was changed to use the same dry-run flag as other commands (pkg/cmd/rollback.go accepting) =server on line 103), it still retrieves the stored manifests (pkg/action/rollback.go line 207). Even with the flag, lookup is not called, so the corrected sentence is correct for both versions. I have not run it directly with Helm 4 (untested).

In summary, the sentence has two errors. First, the meaning that "you can test lookup with these two commands" is wrong (there are no templates to render), and second, running those commands as-is in Helm 3 results in a flag error.

3. What Changed: Summary of the Diff

In the same paragraph of both files, delete|rollback was removed, and one additional sentence was added explaining why it was removed. The rest of the paragraph remains unchanged.

 # docs/chart_template_guide/functions_and_pipelines.mdx (versioned_docs/version-3 의 같은 문단도 같게)
-Keep in mind that Helm is not supposed to contact the Kubernetes API Server during 
-a `helm template|install|upgrade|delete|rollback --dry-run` operation. To test `lookup` 
-against a running cluster, `helm template|install|upgrade|delete|rollback --dry-run=server`
-should be used instead to allow cluster connection.
+Keep in mind that Helm is not supposed to contact the Kubernetes API Server during
+a `helm template|install|upgrade --dry-run` operation. To test `lookup` against a
+running cluster, `helm template|install|upgrade --dry-run=server` should be used
+instead to allow cluster connection. `helm uninstall` and `helm rollback` do not
+render templates, so `lookup` is not called by these commands.

Trailing spaces at the ends of old lines were also deleted, making the number of deleted lines appear larger than the number of sentences. The PR body includes quotes of the old sentences, the reasons why the two commands must be omitted (source files and flag definitions), the table from Section 1, and ParseBool errors, and two things I failed to do. They are: "I didn't runyarn build locally, it's just a text change in a single paragraph" and "I didn't fix the translated version belowi18n/ ". At the end of the post, I added a sentence stating that I wrote it with the help of AI and reviewed it myself. I attached the DCO sign-off (required by helm-www's CONTRIBUTING)Signed-off-by) and an SSH signature to the commit.

4. Response: Approved in 1 hour 19 minutes, merged in 15 hours 54 minutes

The bots only handled the size label and previews; there were no review bots or inline comments. The maintainer's words were /lgtm was all it took.

What is worth noting is the failure at 00:50. GitHub simply indicated that this run "appears to have failed due to a workflow file issue," and because no jobs were started, there are no logs. The base commit's typos.yml was a standard two-step process, and right before the merge, after incorporating main, the exact same workflow passed in 7 seconds. The two commits that entered main in the meantime only changed documentation. The cause was not identified (unconfirmed). Although it seemed like a failure unrelated to our changes, honestly, we did not record this failure in our ledger nor did we take separate action for it. The state of the ledger remained "pending review" the whole time. Thanks to the maintainer merging main and re-running the checks, it was merged with a green light.

The merge commit dc74ea9b was authored by our account, and the message consisted of our commit message appended with the PR number and a line from the maintainer's Co-authored-by because the commit incorporating main entered the branch under the maintainer's name. On 2026-10-17, we opened the relevant documentation page on helm.sh and confirmed that the corrected sentence was visible.

5. What We Learned: Tips for Open Source Contribution

• a|b|c|d|e Let's break down the list one by one. When commands are listed together in a group, it is easy for the person who wrote them first to verify only a few representative ones and tack the rest onto the same line. Running five of them one by one takes only a few minutes, and if even one of them throws an error, that becomes the first line of the PR.
• The source code is more accurate than the help text when it comes to flag types. --dry-run An identical name like was a string in some commands and a boolean in others. StringVar and BoolVar If you show these two lines, the maintainer has nothing extra to check.
• For documents with multiple versions, fix them across all versions and specify which parts were not fixed. We updated both the current documentation and the Helm 3 version documentation, and stated in the body that the translations were not touched. Checking via GitHub code search on 2026-10-17, the old sentence (delete|rollback) still remains in 11 translated versions, including Korean. This is a candidate for our next contribution, though nothing has been submitted yet.
• Look into check failures even if they are not your fault. This failure seemed unrelated to our changes and was cleaned up by the maintainer. Still, if the person who submitted the PR had first left a brief note saying, "This failure appears to be a workflow issue that finished without work," the maintainer would have had to guess less. It is worth revisiting whether our ledger's tracking script catches such failures.
• There can be a delay between approval and merging. Approval came in 1 hour and 19 minutes, but the merge was processed in turn as the maintainer cleared out other PRs. There was no need to rush them in the meantime.

Titi's word. There was a note saying, "Just ask these five friends!" but the fourth and fifth friends were unable to hear the question. When I called them out one by one, the fifth friend asked back, "What is a server?" After crossing out the two names on the note and writing a one-line reason, I received a "Good" stamp. I will also keep in mind that eleven notes in other languages are still left as they are.

Link

All materials were accessed on 2026-10-17.

• PR: helm/helm-www#2307 (Merge commit dc74ea9b)
• Modified document (Base commit): functions_and_pipelines.mdx, version-3/.../functions_and_pipelines.md, CONTRIBUTING.md
• Reflected document: https://helm.sh/docs/chart_template_guide/functions_and_pipelines/
• Helm 소스(v3.22.1): pkg/engine/funcs.go, pkg/engine/engine.go, pkg/action/action.go, pkg/action/rollback.go, pkg/action/uninstall.go, cmd/helm/install.go, cmd/helm/rollback.go, cmd/helm/uninstall.go
• Helm 소스(v4.3.1): pkg/cmd/uninstall.go, pkg/cmd/rollback.go, pkg/action/rollback.go
• PR prepared in the same batch: Part 2, grafana-community/helm-charts#896