chore(upgrade-argocd): bump ArgoCD chart to 10.7.2 / ArgoCD v3.5.2 - #1097
Draft
iliesmrf wants to merge 1 commit into
Draft
chore(upgrade-argocd): bump ArgoCD chart to 10.7.2 / ArgoCD v3.5.2#1097iliesmrf wants to merge 1 commit into
iliesmrf wants to merge 1 commit into
Conversation
Bumps the workload-cluster ArgoCD release from chart 8.5.6 (ArgoCD v3.1.7) to 10.7.2 (v3.5.2), a chain of minor releases within the same major line (3.x). argocdInfra is out of scope (not managed here). Reviewed against the official upgrade guides (3.1->3.2, 3.2->3.3, 3.3->3.4, 3.4->3.5): none of the breaking changes touch our config (RBAC policy.csv, oidc.config, resource.exclusions, OCI/Harbor repo auth). timeout.reconciliation default drops 180s->120s (not overridden here, more frequent reconciliation, non-breaking). Operational note for rollout: the ApplicationSet CRD now exceeds the client-side apply size limit (breaking change in 3.3), may need server-side apply with --force-conflicts on first sync since ArgoCD manages its own CRDs here when crds.install: true (argo_infra_ownership is false on this release).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issues liées
Issues numéro : #1098
Quel est le comportement actuel ?
Le release ArgoCD du cluster workload est sur le chart 8.5.6 (ArgoCD v3.1.7).
Quel est le nouveau comportement ?
Bump du chart ArgoCD du cluster workload de 8.5.6 (ArgoCD v3.1.7) à 10.7.2 (v3.5.2), soit une chaîne de releases mineures au sein de la même ligne majeure (3.x).
argocdInfraest hors périmètre (non géré ici).Revue effectuée par rapport aux guides d'upgrade officiels (3.1→3.2, 3.2→3.3, 3.3→3.4, 3.4→3.5) : aucun des breaking changes ne touche notre configuration (RBAC
policy.csv,oidc.config,resource.exclusions, auth OCI/Harbor). Le défauttimeout.reconciliationpasse de 180s à 120s (non surchargé chez nous, reconciliation plus fréquente, non cassant).Cette PR introduit-elle un breaking change ?
Non, pour le code de ce repo. Point opérationnel à surveiller au rollout (pas un breaking change de config) : la CRD
ApplicationSetdépasse désormais la limite de taille pour un apply client-side (breaking change introduit en 3.3). Le releaseargocdgère ses propres CRDs sur ce cluster (crds.install: true,argo_infra_ownershipestfalseici), mais le sync qui le déploie utilise déjàServerSideApply=truepar défaut (dso-appset.yaml.j2), ce qui couvre normalement ce cas. À surveiller au premier sync post-upgrade : en cas d'échec par conflit de propriété de champ (409), ajouter ponctuellementForce=trueen plus deServerSideApply=true.Autres informations