argo-cd: Unable to use helm CLI against helm releases that have been deployed by ArgoCD

This is a critical issue BTW !

Seems like Argo uses Helm as generator of YAML manifests only thru helm template. Please be advised that helm template is not aware about the server side namely if your helm chart has some conditions based on the existence of API Versions Capabilities.

Similar GH issues:

• https://github.com/helm/helm/issues/3377
• https://github.com/argoproj/argo-cd/issues/3631
• https://github.com/databus23/helm-diff/issues/165

Frankly, this is a closed ticket that you’re hijacking. Use a discussion or Slack or something.

Kubectl can make a single change, and ArgoCD will stomp on it too. The amount of damage you’re likely to experience from that is much lower than using helm and being surprised by the huge jitter you’d get.

I see, but to be honest, I don’t see any bad with that.

Wouldn’t that be the same behavior if someone change a resource directly with kubectl?

I understand how ArgoCD owns the resource but, at the same time, it is not the only system using/managing it. There are cases where an operator in the cluster can touch a resource deployed with ArgoCD. The expected behavior would be that ArgoCD reverts any change if configured in auto-sync.

I don’t get why precluding that from happening with Helm. That should be a user’s choice. In my opinion, that limits how we can use Helm in combination with ArgoCD with not much benefit.

I’m not the person who made the choice. But the idea is that ArgoCD owns the resource, so if you want information about it, you should be using the ArgoCD system. That could be looking at the git configuration to see what you asked for, or the ArgoCD ui/cli to see how synced the git state is with the kubernetes deployment.

If you want to upgrade a resource, edit the git configuration for the resource and wait for ArgoCD to apply your changes.

If the resource was visible to helm, there’s a risk of someone trying to upgrade the resource manually using helm. That would then be overwritten by ArgoCD, which is tasked with owning the resource.

If you don’t want to use ArgoCD to own a resource, then don’t give it a resource in the first place.

Hi - We use install Helm to install the applications but delete it afterward. You won’t be able to use the helm CLI tool to work with apps. Instead, you can use the argocd and kubectl CLI tools.

Yeah @tyriis, it’s sad to see that. This would open the project to a wide range of new use cases

Hey @jsoref 👋🏻

Out of curiosity, what is the reason behind this design choice? Can’t we achieve the same using helm upgrade --install instead of helm template (if that is how ArgoCD uses Helm behind the scene)?

I think that will give more flexibility to those who, like me, have other tools built on top of Helm working on the same releases deployed with ArgoCD. This design choice forces us to use Helm only for “templating” while other use cases exist.

To me, it seems like a breaking feature. I’m curious to hear what others think.

@alexec Thanks for the clarification. This is expected behaviour. I will close this issue then.

@gadiener have started a discussion on this topic here: https://github.com/argoproj/argo-cd/discussions/7759 but obviously, the interest to change it is really limited 😕

@alexec Can this be added in the official docs? I tried to find this information there but didn’t find it, and I think this is an important piece of information that users should be aware of.

it is in the official docs. It’s one of the FAQ: https://argo-cd.readthedocs.io/en/stable/faq/