Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2021-01-28T15:33:05.787Z
Answers: 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.
Answers: fourslashw
Answers: CC BY-SA 4.0
Answers: 2021-01-28T07:36:09.110Z
Answers: 2021-01-28T07:36:09.110Z
Answers: maplebird
Body: <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>
  
Tags: <jenkins><kubernetes><deployment><helm><kubernetes-helm>
Title: Is there a way to combine helm with some other tool for k8s configuration management without conflicts?
UserDisplayName: fourslashw
ThreadText: # 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](https://helm.sh/docs/helm/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.  
  
  ---
  
  