argocd with this plugin ignores namespace definitions

[travisghansen]

argocd with this plugin ignores namespace definitions

[travisghansen]

The namespace should be the namespace of the app in argocd. It’s not recommended to set the namespace in your helmfiles.

[Nexus2k]

Not recommend != not supported. I'll rather not use argocd and your plugin then. Thanks for getting back to me.

[travisghansen]

I’m happy to look into it but I’m not sure what you want the plugin to do. You will be limited by the limitations of both argocd and helmfile.

This plugin itself does nothing more than run helmfile template and hands the resultant files/output to argocd. The script doesn’t manipulate the contents of the rendered files at all.

[Nexus2k]

Let's say we have a complicated helm deployment called base-services which deploys different helm charts in different namespaces in one go. E.g. 01-kube-prometheus.yaml in namespace: monitoring / 05-nginx-controller.yaml in namespace: default / 80-hairpin-proxy.yaml in namespace: hairpin-proxy

I would prefer to not split that bundle of deployments to different argocd apps if possible.

If I deploy today using argocd-helmfile it does create stuff like service-accounts or role-bindings in either the argocd app namespace or if it's empty in default namespace. While if I do the same with regular helmfile sync it does respect the namespace property for each of the charts.

[travisghansen]

Have you been able to achieve that generally with argocd? I don’t think that’s a thing with argocd generally, and certainly doesn’t follow any best practices.

When argocd applies the yaml behind the scenes it explicitly calls out -n to match the namespace of the app. Using an app in 1 namespace to deploy assets to another namespace would be highly irregular (if not impossible) to my knowledge.

If you do create separate apps for each ns you can still use your centralized hemfile repo, but you would add a label on the releases instead of using the namespace property and then filter with labels.