I’ve been using Argo CD for GitOps automation for a very long time. I have it manage itself too! The other day I noticed that there was a new major version of Argo CD, so I decided to upgrade my stuff too. It did not go smoothly, though it wasn’t an issue with Argo CD itself.

It was the usual problem of Helm charts renaming and moving around stuff in their values.yaml, which results in significant breakage for (from an user perspective) no good reason. I summed up what I learned so others don’t have to play around with it so much.

All of the breakage was centered around the Ingress configuration. I have Traefik as my ingress controller and it terminates HTTPS for me, so the Argo server would run “insecure” behind that. The correct configuration took a while to figure out, because (obviously) once I screwed it up, I couldn’t connect to Argo in the browser, and I had to first fix my local kubeconfig so I could port-forward to the Argo server pod to see what was going on.

--insecure

Crucially, the insecure option has to be specified under configs.params.server.insecure as string true. The Helm chart template looks at this configuration option to decide which port to use so if you used to use server.extraArgs to pass in --insecure, that will no longer work. It has to be under configs.

configs:
  params:
    server.insecure: "true"

Hosts

Before, under server.ingress I’d have a hosts option and a tls option with the same configuration in it. The host name is now preferably set using the global.domain option at the top level of values.

global:
  domain: argo.example.com

The tls configuration also changed to extraTls (though with the same value) and I got the impression you also needed to include ingressClassName now, so that got done too.

server:
  ingress:
    ingressClassName: traefik
    extraTls:
    - hosts:
      - argo.example.com

Once Argo pulled in these value changes, everything worked just fine again.