Elgato_dark/argo-cd
1
0
Fork 0
mirror of https://github.com/argoproj/argo-cd synced 2026-04-21 17:07:16 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 22

docs: upgrade instructions for 3.3 with SSA (#25649)

Browse source 
Signed-off-by: reggie-k <regina.voloshin@codefresh.io>
Signed-off-by: Regina Voloshin <regina.voloshin@codefresh.io>
Co-authored-by: Nitish Kumar <justnitish06@gmail.com>
This commit is contained in:
Regina Voloshin 2025-12-15 16:28:34 +02:00 committed by GitHub
parent d9fe8a4175
commit e58d75f1da
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
2 changed files with 26 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
docs/operator-manual/upgrading/3.2-3.3.md
View file

@ -2,6 +2,31 @@
## Breaking Changes
### ApplicationSet CRD exceeds the size limit for client-side apply
In this version, the ApplicationSet CRD exceeds the size limit for client-side apply, meaning that the previous upgrade methods will result in `The CustomResourceDefinition "applicationsets.argoproj.io" is invalid: metadata.annotations: Too long: may not be more than 262144 bytes`
In order to avoid this issue, it is now required to upgrade Argo CD using Server Side Apply (SSA) along with `resolve conflicts`.
SSA does not store the ApplicationSet fields in `last-applied` annotation, thus not impacted by the annotation size limitation.
The `--force-conflicts` flag allows the apply operation to take ownership of fields that may have been previously managed by other tools (such as Helm or a previous `kubectl apply`). This is necessary for upgrades. Note that any custom modifications you've made to fields that are defined in the Argo CD manifests (like `affinity`, `env`, or `probes`) will be overwritten. However, fields not specified in the manifests (like `resources` limits/requests or `tolerations`) will be preserved.
#### Upgrading Argo CD which is managing itself
When Argo CD is upgraded using an Argo CD Application, it is required to enable Server-Side Apply in the Application spec:
``` yaml
syncOptions:
- ServerSideApply=true
```
With this configuration, Argo CD will add the `resolve conflicts` option automatically.
#### Upgrading Argo CD manually using Kustomize or plain manifests
When Argo CD is upgraded manually using plain manifests or Kustomize overlays, it is required to upgrade it with `--server-side --force-conflicts`. For example, `kubectl apply -n argocd --server-side --force-conflicts -f manifests/install.yaml`
#### Upgrading Argo CD manually using Helm
Users upgrading Argo CD manually using `helm upgrade` are not impacted by this change, since Helm does not use client-side apply and does not result in creation of the `last-applied` annotation.
### Source Hydrator Now Tracks Hydration State Using Git Notes
Previously, Argo CD's Source Hydrator pushed a new hydrated commit for every DRY (source) commit, regardless of whether any manifest files (`manifest.yaml`) actually changed. This was necessary for the hydrator to track which DRY commit had last been hydrated: it embedded this information in the `hydrator.metadata` file's `drySha` field in each hydrated commit.
@ -77,4 +102,3 @@ If any existing manifests become corrupted, please follow the instructions in th
Kustomize 5.8.0 also resolves an issue where namespaces were not properly propagated to Helm charts.
If you rely on Helm charts within kustomization files, please review the details in the associated fix:
[kubernetes-sigs/kustomize#5940](https://github.com/kubernetes-sigs/kustomize/pull/5940).

1
mkdocs.yml
View file

@ -134,6 +134,7 @@ nav:
- operator-manual/server-commands/additional-configuration-method.md
- Upgrading:
- operator-manual/upgrading/overview.md
- operator-manual/upgrading/3.2-3.3.md
- operator-manual/upgrading/3.1-3.2.md
- operator-manual/upgrading/3.0-3.1.md
- operator-manual/upgrading/2.14-3.0.md