We are setting up our SaaS product with ArgoCD using a Helm chart.
As part of the initial deployment, we run a few K8s jobs. To make sure that they run only initially, the job templates are guarded with an "not if .Release.isUpgrade".
Alas, this Helm flag is never set by ArgoCD (I am aware that there is a statement about that in the docs at https://argo-cd.readthedocs.io/en/stable/user-guide/helm/#helm-hooks ).
This can now lead to the situation that we make changes to the configuration and run a sync that also affects the job spec - one common example is changing the image tag. We have a common setting for the tag that is by default used for all our container images, including the jobs (but can be overridden for individual services to rollout patches).
What now happens if we roll out an update is that ArgoCD will attempt to also change the image version of the job spec, leading to a "field is immutable" error and causing the entire deployment to end up (and stay!) "out of sync", see screnshots below.
We are currently using v2.0.3.
Are there any plans to address these and similar issues? Like making ArgoCD aware of whether a sync is an initial helm install or a helm upgrade? Or does anyone have a proposal for working around this issue?


We are setting up our SaaS product with ArgoCD using a Helm chart.
As part of the initial deployment, we run a few K8s jobs. To make sure that they run only initially, the job templates are guarded with an "not if .Release.isUpgrade".
Alas, this Helm flag is never set by ArgoCD (I am aware that there is a statement about that in the docs at https://argo-cd.readthedocs.io/en/stable/user-guide/helm/#helm-hooks ).
This can now lead to the situation that we make changes to the configuration and run a sync that also affects the job spec - one common example is changing the image tag. We have a common setting for the tag that is by default used for all our container images, including the jobs (but can be overridden for individual services to rollout patches).
What now happens if we roll out an update is that ArgoCD will attempt to also change the image version of the job spec, leading to a "field is immutable" error and causing the entire deployment to end up (and stay!) "out of sync", see screnshots below.
We are currently using v2.0.3.
Are there any plans to address these and similar issues? Like making ArgoCD aware of whether a sync is an initial helm install or a helm upgrade? Or does anyone have a proposal for working around this issue?