ArgoRollout & ArgoCd : Configmap update issue during rollout

[MaximeBOUDIER]

Context

I’m using Argo Rollouts with Argo CD (for GitOps) for progressive canary rollouts (~40 minutes, gradually increasing traffic).

To safely handle ConfigMap changes, I use the “versioned ConfigMap” pattern described in this kind documentation suggested in this discussion

Contrary to the doc I use Helm (not Kustomize) to render ConfigMaps, but the outcome is the same : one configmap for the stable replicaSet and an other CM object for the Canary ReplicaSet.

• When ConfigMap values change, Helm renders a new configmap name to version it that looks like :
  • myapp-envvars-[cm-hash_stable] (current stable, already deployed in my cluster)
  • myapp-envvars-[cm-hash_canary] (new canary that will be deployed and used by my canary pods)
• The stable ReplicaSet references the stable ConfigMap; the canary ReplicaSet references the canary ConfigMap.
• ConfigMaps are annotated with argocd.argoproj.io/sync-options: PruneLast=true so the stable configmap is cleaned after the argocd Sync | after the rollout.

This works in the happy path.

Problem

If the AnalysisRun fails during the canary, Argo Rollouts auto‑rolls back to the previous revision and Argo CD marks the app as Degraded. However, the “stable” ConfigMap still gets pruned, so the stable pods fail to start because their referenced ConfigMap no longer exists.

• Expected
  On a failed analysis (and auto‑rollback), the stable ConfigMap referenced by the stable ReplicaSet should not be pruned. Cleanup should occur only when the Argo CD app is Healthy that is the case only when the rollout is promoted.

Here is a diagram that illustrates the flow:

Questions

1. Is this pruning behavior expected in Argo CD (i.e., pruning even when the app is Degraded)? Is there an Argo CD setting to prevent this?
2. Are there other recommended practices to manage ConfigMap changes with Argo Rollouts canary + Argo CD ?

Thank you for your help !