<p>I'm think I'm about to reinvent the wheel here. I have all the parts but am thinking: Somebody must have done this (properly) before me.</p>
<p>We have a a jenkins CI job that builds <code>image-name:${BRANCH_NAME}</code> and pushes it to a registry. We want to create a CD job that deploys this <code>image-name:${BRANCH_NAME}</code> to kubernetes cluster. And so now we run into the problem that if we call <code>helm upgrade --install</code> with the same <code>image-name:${BRANCH_NAME}</code> nothing happens, even if <code>image-name:${BRANCH_NAME}</code> now actually refers to a different sha256 sum. We (think we) understand this.</p>
<p>How is this generally solved? Are there best practices about this? I see two general approaches:</p>
<ol>
<li>The CI job doesn't just create <code>image-name:${BRANCH_NAME}</code>, it also creates a unique tag, e.g. <code>image-name:${BRANCH_NAME}-${BUILD_NUMBER}</code>. The CD job never deploys the generic <code>image-name:${BRANCH_NAME}</code>, but always the unique <code>image-name:${BRANCH_NAME}-${BUILD_NUMBER}</code>.</li>
<li>After the CI job has created <code>image-name:${BRANCH_NAME}</code>, its SHA256 sum is retrieved somehow (e.g. with <code>docker inspect</code> or <a href="https://github.com/containers/skopeo" rel="nofollow noreferrer"><code>skopeo</code></a> and helm is called with the SHA256 sum.</li>
</ol>
<p>In both cases, we have two choices. Modify, commit and track a <code>custom-image-tags.yaml</code> file, or run helm with <code>--set </code>parameters for the image tags. If we go with option 1, we'll have to periodically remove &quot;old tags&quot; to save disk space.</p>
<p>And if we have a single CD job with a single helm chart that contains multiple images, this only gets more complicated.</p>
<p>Surely, there must be some opinionated tooling to do all this for us.</p>
<p>What are the ways to do this without re-inventing this particular wheel for the 4598734th time?</p>
<h1><code>kbld</code> gets me some of the way, but breaks helm</h1>
<p>I've found <a href="https://carvel.dev/kbld/" rel="nofollow noreferrer"><code>kbld</code></a>, which allows me to:</p>
<pre><code>helm template my-chart --values my-vals.yml | kbld -f - | kubectl apply -f -
</code></pre>
<p>which basically implements 2 above, but now helm is unaware that the chart has been installed so I can't <code>helm uninstall</code> it. :-( I'm hoping there is some better approach...</p>

Peter V. Mørch
<p><code>kbld</code> can also be used &quot;fully&quot; with helm...</p>
<p>Yes, the <a href="https://carvel.dev/kbld/" rel="nofollow noreferrer">docs</a> suggest:</p>
<pre><code>$ helm template my-chart --values my-vals.yml | kbld -f - | kubectl apply -f -
</code></pre>
<p>But this also works:</p>
<pre><code>$ cat kbld-stdin.sh

#!/bin/bash
kbld -f -

$ helm upgrade --install my-chart --values my-vals.yml --post-renderer ./kbld-stdin.sh
</code></pre>
<p>With <code>--post-renderer</code>, <code>helm list</code>, <code>helm uninstall</code>, etc. all still work.</p>
