<p>Helm isn't made to be used this way.  If you'd prefer to use a static deployment, you're better off using a plain Kubernetes manifest.  Then, people changing the image field won't break your release.</p>
<p>You can easily convert it to one simply by running <a href="https://helm.sh/docs/helm/helm_get_manifest/" rel="nofollow noreferrer">helm get manifest</a> command</p>
<p>Helm is used to manage release versions.  I.e. every new release (and a docker image change definitely qualifies as one), you would push a change to your helm chart.</p>
<p>The other alternative you have is defining docker image as a value.  Then you can pass a command-line argument to replace the image tag with a new one and re-run helm from Jenkins any time you have a new deploy.</p>
<p>Example:</p>
<p>in values.yaml:</p>
<pre><code>image: 
  repo: foo
  tag: bar
</code></pre>
<p>On command line when running helm:</p>
<pre><code>helm upgrade --install my-app --set image.tag=newtag
</code></pre>
<p>Final, and least recommended way is to use a mutable tag (i.e. &quot;master&quot;) and set your <code>ImagePullPolicy</code> to <code>Always</code>.  This way, when you have a deploy, you just need to bounce all the pods in your deployment/daemonset/statefulset object.</p>

CC BY-SA 4.0
2021-01-28T15:33:05.787Z
I think I'll just move my helm release to another host which is accessible from jenkins and  use your solution with command line argument then.
fourslashw
CC BY-SA 4.0
2021-01-28T07:36:09.110Z
2021-01-28T07:36:09.110Z
maplebird
<p>Currently I have a k8s project with multiple services which are managed by a helm chart. Said helm chart is installed on my local machine and I want to keep it this way if it's possible. But now I need to provide a simple user-friendly way to change versions of some service's docker images for other people. I was thinking about creating a jenkins task which would allow changing &quot;image&quot; field for those services, but it would create conflicts with my helm release: next time I update something with helm, it would rollback jenkins &quot;image&quot; field changes to the values in my helm chart.</p>
<p>Is there a simple way to resolve this conflict, like saying helm not to change &quot;image&quot; field? If not, how can I continue using helm for project configuration while allowing &quot;image&quot; field changes from jenkins?</p>

<jenkins><kubernetes><deployment><helm><kubernetes-helm>
Is there a way to combine helm with some other tool for k8s configuration management without conflicts?
fourslashw
# Is there a way to combine helm with some other tool for k8s configuration management without conflicts?

(Asked by: username_0 on 2021-01-27)

Currently I have a k8s project with multiple services which are managed by a helm chart. Said helm chart is installed on my local machine and I want to keep it this way if it's possible. But now I need to provide a simple user-friendly way to change versions of some service's docker images for other people. I was thinking about creating a jenkins task which would allow changing "image" field for those services, but it would create conflicts with my helm release: next time I update something with helm, it would rollback jenkins "image" field changes to the values in my helm chart.

Is there a simple way to resolve this conflict, like saying helm not to change "image" field? If not, how can I continue using helm for project configuration while allowing "image" field changes from jenkins?

**Tags:** jenkins, kubernetes, deployment, helm, kubernetes-helm


---

## 1 answers

### Answer by username_1 on 2021-01-28. Score: 2 | Accepted answer

Helm isn't made to be used this way.  If you'd prefer to use a static deployment, you're better off using a plain Kubernetes manifest.  Then, people changing the image field won't break your release.
You can easily convert it to one simply by running helm get manifest command
Helm is used to manage release versions.  I.e. every new release (and a docker image change definitely qualifies as one), you would push a change to your helm chart.
The other alternative you have is defining docker image as a value.  Then you can pass a command-line argument to replace the image tag with a new one and re-run helm from Jenkins any time you have a new deploy.
Example:
in values.yaml:
image: 
  repo: foo
  tag: bar

On command line when running helm:
helm upgrade --install my-app --set image.tag=newtag

Final, and least recommended way is to use a mutable tag (i.e. "master") and set your ImagePullPolicy to Always.  This way, when you have a deploy, you just need to bounce all the pods in your deployment/daemonset/statefulset object.

> **Comments:**
> **username_0**: I think I'll just move my helm release to another host which is accessible from jenkins and  use your solution with command line argument then.  

---

