Closed jewilmeer closed 7 years ago
Maybe globals work? https://github.com/kubernetes/helm/blob/master/docs/charts.md#global-values
This looks more promosing: https://github.com/kubernetes/helm/blob/master/docs/chart_template_guide/named_templates.md
Just to give some context:
Charts are parsed as Golang text/template strings. On top of that, an extra superset of template functions is injected using the Sprig library.
In this case, named templates come from the standard Go library, so this can be used, without any requirements from Helm.
Having said that, the current implementation of Kubecrt considers charts.yml
as one big YAML file, without any template parsing, and it instead sends along all the defined chart configs as-is to Helm. This works for template variables inside chart definitions, but not anywhere else.
This can be fixed though, so you make a good point, this should work as expected 👍
I just tested this in a test chart:
{{- define "contacts" }}
contacts:
- jean@blendle.com
{{- end }}
apiVersion: v1
charts:
- blendle/web:
version: ~> 0
values:
{{- template "contacts" }}
This works as expected when passed into kubecrt
.
The problem, as you can see, is that you need to match the spacing in the define block, instead of in the template call.
Ideally, you'd want to do something like {{- template "contacts" | ident 6 }}
, but that doesn't work:
template: test:9: unexpected "|" in template clause
Now, this is expected, because template
takes an optional second argument (which is the scope within which the template's definition is executed). So the correct usage would be {{- template "contacts" . | indent 6 }}
. But even when fixing that, it still doesn't work:
template: test:11:41: executing "test" at <6>: wrong type for value; expected string; got map[string]interface {}
This seems fixable, but I haven't found the cause yet.
Some projects (especially the old ones), have a lot of envs & secrets configured. If you have a couple of deployments, you need to change them for all those deployments. Having a way of centralising those values would be very helpful.
Some ideas: