tpl fails when called in a template rendered in the subchart context

[Kytech]

When calling tpl from a template being rendered in the context of a subchart (using {{ include "common.configmap" .Subcharts.common }} as detailed in PR #9957, which introduced the .Subcharts object to support such a use case), the following error occurs:

error calling include: template: prometheus/charts/common/templates/_configmap.yaml:39:8: executing "common.configmap.tpl" at <tpl (toYaml $configs) .>: error calling tpl: cannot retrieve Template.Basepath from values inside tpl function

It appears that a similar issue (#10082) occurred before due to .Template being removed from the scope at one point in time and it seems that .Template has been available in the subchart scope previously based on this comment in PR #10084 and the change made in that PR.

I am able to work around this by copying .Template to .Subcharts.common before rendering the subchart-provided template, which seems to indicate that this is indeed the cause of the problem. I'm thinking that this is a regression since PR #10084 would have resulted in .Template being exposed under .Subcharts.<name>.Template as well.

---

Output of helm version:

version.BuildInfo{Version:"v3.9.1", GitCommit:"a7c043acb5ff905c261cfdc923a35776ba5e66e4", GitTreeState:"clean", GoVersion:"go1.18.4"}

Output of kubectl version:

Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.12", GitCommit:"b058e1760c79f46a834ba59bd7a3486ecf28237d", GitTreeState:"clean", BuildDate:"2022-07-13T14:52:41Z", GoVersion:"go1.16.15", Compiler:"gc", Platform:"darwin/amd64"}
Unable to connect to the server: net/http: TLS handshake timeout

Cloud Provider/Platform (AKS, GKE, Minikube etc.): k8s

[github-actions]

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

[Kytech]

@joejulian it looks like this is still a problem. Could we get this re-opened? Not sure if anyone who works on Helm has had a chance to look into this, but it does look like at least one other person has encountered the same issue judging by this issue being mentioned elsewhere.

[omry-arpaly]

I've also run into the same situation, and this is using Helm 3.10.3 and 3.11.0-rc2.
It appears the whole "$" context is missing when running a template positioned in a subchart... (in my case - calling template A from subchart X, when template A is defined in subchart Y). [Both charts are "siblings" under a mutual umbrella chart]

[yverbin]

I have same issue with official grafana chart (https://grafana.github.io/helm-charts ) when use it as dependency

[github-actions]

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

[omry-arpaly]

It's still alive and annoying - any of the maintainers care to commnet? 🙏

[Kytech]

Would love to hear some updates on this myself. If I had the time available to go back through and try to implement a fix myself, I would gladly put together a fix and a PR, but I've had many other things that have had to take priority over looking into this, especially since I haven't been working on writing helm charts as part of my work for a while now. I've kept my eye on this, but I can't say when, or if, I'll be able to take a deeper look into this any time soon.

[Lazken]

Just ran into the same issue. Grafana chart can not be used in a dependency context at this time.

[github-actions]

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.

[Kytech]

After opening this issue more than a year ago and not receiving any updates, coupled with the fact that I haven't been responsible for helm charts impacted by this bug for a while now and I have too many other demands on my time, I'm not going to request this issue be re-opened. If this issue comes up again for me in the future when I have the time, maybe I'll try to create a fix myself, but if anyone else is encountering this problem, please feel free to just open a new issue and reference this one for further background on the problem. Seems like it did not receive much attention from any maintainers or contributors after initial triage.

[vio-f]

This is still happening - can this issue be re-opened please ?!

[CrazyByDefault]

This is a regression and is definitely an issue, can we at least not auto-close this even if people are not able to work on it today? At the least, it prevents duplicates, and at best, it allows for discovery of this bug when others run into this issue.

[gjenkins8]

I had not seen this issue until now. I will try and find time to triage next week

[bebosudo]

Hello, I just got bitten by this too.. @gjenkins8 did you have any luck debugging this?

For anyone interested in working on this, I created the smallest reproducible I could think of:

# ./parentchart/Chart.yaml
apiVersion: v2
name: parentchart
description: A Helm chart for Kubernetes
type: application
version: 0.1.0
appVersion: "1.16.0"

# ./parentchart/values.yaml
subchart:
  port: "8081"

# ./parentchart/templates/pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: parentchart-nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: {{ include "subchart.podPortNumber" .Values.subchart }}

# ./parentchart/charts/subchart/Chart.yaml
apiVersion: v2
name: subchart
description: A Helm chart for Kubernetes
type: application
version: 0.1.0
appVersion: "1.16.0"

# ./parentchart/charts/subchart/values.yaml
port: "8080"

# ./parentchart/charts/subchart/templates/pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: subchart-nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: {{ include "subchart.podPortNumber" .Values }}

# ./parentchart/charts/subchart/templates/_helpers.tpl
{{- define "subchart.podPortNumber" -}}
{{ tpl .port . }}
{{- end -}}

This is what I get when running it (slightly different error message from when the issue was first opened):

$ helm template testrelease .
Error: template: parentchart/charts/subchart/templates/pod.yaml:10:24: executing "parentchart/charts/subchart/templates/pod.yaml" at <include "subchart.podPortNumber" .Values>: error calling include: template: parentchart/charts/subchart/templates/_helpers.tpl:2:3: executing "subchart.podPortNumber" at <tpl .port .>: error calling tpl: cannot retrieve Template.Basepath from values inside tpl function: 8081: "BasePath" is not a value

Here are my helm and kubectl versions:

$ helm version 
version.BuildInfo{Version:"v3.11", GitCommit:"", GitTreeState:"", GoVersion:"go1.20.1"}
$ kubectl version 
Client Version: v1.28.1

[bebosudo]

I just tried the latest helm 3.14 release, and it solved the problem, at least my usecase! 🎉

I'd guess that the bit that solved it was that

Allow a nested tpl invocation access to defines

Which I'd guess is a byproduct of PR Speed up tpl #11351, which took 1+ years to get merged and only landed in helm 3.14, released 3 weeks ago.

[Kytech]

I just tried the latest helm 3.14 release, and it solved the problem, at least my usecase! 🎉

If your use case is the same as the one illustrated in your minimum example, your use case is probably a bit different than the one I had when I initially reported this issue (where I was referencing .Template in the subchart), so it still may not be fixed for all use cases yet. I'll have to test this again on v3.14.0 when I have a chance to, unless someone beats me to it. It will probably be a little while until I could look into this further - I have a thesis to finish before I can actually sit down and try to aid in debugging or draw up a PR.

[github-actions]

This issue has been marked as stale because it has been open for 90 days with no activity. This thread will be automatically closed in 30 days if no further activity occurs.