github.com/argoproj/argo-cd/v3@v3.2.1/docs/operator-manual/upgrading/3.1-3.2.md (about)

     1  # v3.1 to 3.2
     2  
     3  ## Breaking Changes
     4  
     5  ### Hydration paths must now be non-root
     6  
     7  Source hydration now requires that every application specify a non-root path.
     8  Using the repository root (for example, "" or ".") is no longer supported. This change ensures
     9  that hydration outputs are isolated to a dedicated subdirectory and prevents accidental overwrites
    10  or deletions of important files stored at the root, such as CI pipelines, documentation, or configuration files.
    11  
    12  Previously, it was possible for hydration to write manifests directly into the repository root. While convenient, this had two major drawbacks:
    13  
    14  1. Hydration would wipe and replace files at the root on every run, which risked deleting important files such as CI/CD workflows, project-level READMEs, or other configuration.
    15  2. It made it harder to clearly separate hydrated application outputs from unrelated repository content.
    16  
    17  To identify affected applications, review your Application manifests and look for `.spec.sourceHydrator.syncSource.path` values that are empty, missing,
    18  `"."`, or otherwise point to the repository root. These applications must be updated to use a subdirectory path, such as `apps/guestbook`.
    19  
    20  After migration, check your repository root for any stale hydration output from earlier versions.
    21  Common leftovers include files such as `manifest.yaml` or `README.md`. These will not be cleaned up
    22  automatically and should be deleted manually if no longer needed.
    23  
    24  ## Argo CD Now Respects Kustomize Version in `.argocd-source.yaml`
    25  
    26  Argo CD provides a way to [override Application `spec.source` values](../../user-guide/parameters.md#store-overrides-in-git)
    27  using the `.argocd-source.yaml` file.
    28  
    29  Before Argo CD v3.2, you could set the Kustomize version in the Application's `.spec.source.kustomize.version` field,
    30  but you could not set it in the `.argocd-source.yaml` file.
    31  
    32  Starting with Argo CD v3.2, you can now set the Kustomize version in the `.argocd-source.yaml` file like this:
    33  
    34  ```yaml
    35  kustomize:
    36    version: v4.5.7
    37  ```
    38  
    39  ## Deprecated fields in the repo-server GRPC service
    40  
    41  The repo-server's GRPC service is generally considered an internal API and is not recommended for use by external
    42  clients. No user-facing services or functionality have changed. However, if you are using the repo-server's GRPC service
    43  directly, please note field deprecations in the following messages.
    44  
    45  The `kustomizeOptions.binaryPath` field in the `ManifestRequest` and `RepoServerAppDetailsQuery` messages has been
    46  deprecated. Instead of calculating the correct binary path client-side, the client is expected to populate the
    47  `kustomizeOptions.versions` field with the [configured Kustomize binary paths](../../user-guide/kustomize.md#custom-kustomize-versions).
    48  This allows the repo-server to select the correct binary path based on the Kustomize version configured in the
    49  Application's source field as well as any [overrides configured via git](../../user-guide/parameters.md#store-overrides-in-git).
    50  
    51  The `kustomizeOptions.binaryPath` will continue to be respected when `kustomizeOptions.versions` is not set, but this is
    52  not recommended. It will prevent overrides configured via git from being respected. The `kustomizeOptions.binaryPath`
    53  field will be removed in a future release.
    54  
    55  If the repo-server encounters a request with the `kustomizeOptions.binaryPath` field set, it will log a warning message:
    56  
    57  > kustomizeOptions.binaryPath is deprecated, use KustomizeOptions.versions instead
    58  
    59  The `ManifestRequest` and `RepoServerAppDetailsQuery` messages are used by the following GRPC services:
    60  `GenerateManifest`, `GenerateManifestWithFiles`, and `GetAppDetails`.
    61  
    62  ## CronJob Health
    63  
    64  After the upgrade, Application's status may transition to `Degraded` depending on the CronJob health.
    65  
    66  !!! note "CronJob with running jobs"
    67  
    68      If the CronJob is `Degraded` and a new job is scheduled, the health will change to `Healthy` until the active job completes.
    69      This may cause your application to go from `Degraded` to `Healthy` to `Degraded` again. The CronJob status does not contain enough
    70      information to infer the health of the last completed job if there are active jobs.
    71  
    72      If the CronJob constantly has active jobs, the health will be constantly `Healthy` even if the last job failed.
    73  
    74  !!! note "CronJob with suspended state"
    75  
    76      If the CronJob is in a suspended state, the CronJob status will remain Healthy. You can override this behaviour by configuring the
    77      health check using the `resource.customizations.health.batch_CronJob` key in the argocd-cm ConfigMap.
    78  
    79      If you decide to do so and the CronJob is `Suspended`, then the aggregated health of the Application will now be `Suspended` instead of `Healthy`.
    80  
    81  If you do not want your CronJob to affect the Application's aggregated Health, you can configure the annotation
    82  `argocd.argoproj.io/ignore-healthcheck: "true"` on the CronJob resource.
    83  
    84  ## Sanitized project API response
    85  
    86  Due to security reasons ([GHSA-786q-9hcg-v9ff](https://github.com/argoproj/argo-cd/security/advisories/GHSA-786q-9hcg-v9ff)),
    87  the project API response was sanitized to remove sensitive information. This includes
    88  credentials of project-scoped repositories and clusters.
    89  
    90  ## ApplicationSet `resources` field of `status` resource is limited to 5000 elements by default
    91  
    92  The `resources` field of the `status` resource of an ApplicationSet is now limited to 5000 elements by default. This is
    93  to prevent status bloat and exceeding etcd limits. The limit can be configured by setting the `applicationsetcontroller.status.max.resources.count`
    94  field in the `argocd-cmd-params-cm` ConfigMap.