3.1 KiB
v3.1 to 3.2
Argo CD Now Respects Kustomize Version in .argocd-source.yaml
Argo CD provides a way to override Application spec.source values
using the .argocd-source.yaml file.
Before Argo CD v3.2, you could set the Kustomize version in the Application's .spec.source.kustomize.version field,
but you could not set it in the .argocd-source.yaml file.
Starting with Argo CD v3.2, you can now set the Kustomize version in the .argocd-source.yaml file like this:
kustomize:
version: v4.5.7
Deprecated fields in the repo-server GRPC service
The repo-server's GRPC service is generally considered an internal API and is not recommended for use by external clients. No user-facing services or functionality have changed. However, if you are using the repo-server's GRPC service directly, please note field deprecations in the following messages.
The kustomizeOptions.binaryPath field in the ManifestRequest and RepoServerAppDetailsQuery messages has been
deprecated. Instead of calculating the correct binary path client-side, the client is expected to populate the
kustomizeOptions.versions field with the configured Kustomize binary paths.
This allows the repo-server to select the correct binary path based on the Kustomize version configured in the
Application's source field as well as any overrides configured via git.
The kustomizeOptions.binaryPath will continue to be respected when kustomizeOptions.versions is not set, but this is
not recommended. It will prevent overrides configured via git from being respected. The kustomizeOptions.binaryPath
field will be removed in a future release.
If the repo-server encounters a request with the kustomizeOptions.binaryPath field set, it will log a warning message:
kustomizeOptions.binaryPath is deprecated, use KustomizeOptions.versions instead
The ManifestRequest and RepoServerAppDetailsQuery messages are used by the following GRPC services:
GenerateManifest, GenerateManifestWithFiles, and GetAppDetails.
CronJob Health
This realease introduce the addition of CronJob's health, a longtime omitted heath status for a native Kubernetes resource. The health of a CronJob is based on whether or not Jobs are currently running, and if the last completed Job was successful.
After the upgrade, Application's status may transition to Degraded, Progressing or Suspended depending on the CronJob health.
If the CronJob is permanently Suspended, then the aggregated health of the Application will now be Suspended instead of Healthy.
If the CronJob is permanently running jobs, then the aggregated health of the Application will now be Progressing instead of Healthy.
If you do not want your CronJob to affect the Application's aggregated Health, you can configure the annotation
argocd.argoproj.io/ignore-healthcheck: "true" on the CronJob resource.
The health can also be configured globally using the resource.customizations.health.batch_CronJob configuration to change the default behaviour.