<p>Say you need to deploy a public helm chart (like jenkins/jenkins) with a lot of values. I want to write those values over multiple files and also use go templates inside those values files. I then want to compose them together and deploy them. Is there a way to write a meta - level helm chart that creates the values as a manifest then installs a sub chart based on those values?</p>
<p>I’m aware of kustomize, helmfile, and sub charts. I guess none of them just feel like the thing I want (or maybe I’m not using them properly). Kustomize doesn’t support go templates. Helmfile is good for composing and selecting values but not necessarily templating those values files (or maybe it does). Let me know if I’m asking a duplicate.</p>

Ryan
<p><a href="https://github.com/roboll/helmfile" rel="nofollow noreferrer">Helmfile</a> at least does allow Helm-style templating, both in its Helmfile and in individual values files.</p>
<p>Let's say you have some chart, and it needs to know which cluster it's installed in for monitoring purposes.  Ordinarily you'd pass this as a Helm value, but you'd like to have that written down (and scriptable, and be able to pass the same config into multiple charts at the same time).  In Helmfile you can write:</p>
<pre class="lang-yaml prettyprint-override"><code>environments:
  production:
    values:
      - cluster: production.example.com
  testing:
    values:
      - cluster: testing.example.com

releases:
  - name: some-chart
    namespace: some-chart
    chart: ./charts/some-chart
    values:
      - ./charts/some-chart/values.yaml.gotmpl
      - cluster: {{ .Values.cluster }}
</code></pre>
<p>The last block should resemble <code>helm install</code> arguments, but there are two bits of magic there.  The <code>{{ .Values.cluster }}</code> is a Go <code>text/template</code> block, almost like what you'd do in a Helm chart (the exact template functions are a little different).  Or, if you reference a <code>*.gotmpl</code> file, Helmfile runs the template engine over that file before supplying it as input to helm.</p>
<pre class="lang-yaml prettyprint-override"><code># values.yaml.gotmpl
{{-/* enable profiling but only in testing */}}
profiling: {{ eq .Environment.Name &quot;testing&quot; }}
</code></pre>
<p>Like with plain Helm, it's possible to go overboard with the templating.  It can also be a little bit confusing in that accessing undefined properties is generally an error and not <code>nil</code>, and that the <code>helmfile.yaml</code> gets rendered multiple times (for the most part if you define a per-environment value it <em>must</em> be defined in every environment).  But, this does give you a very generic way to provide per-chart settings, or to define a chart setup that's almost but not quite the same in different environments.</p>
