Este conteúdo não está disponível no idioma selecionado.
Chapter 1. Red Hat OpenShift GitOps release notes
Release notes contain information about new and deprecated features, breaking changes, fixed issues, and known issues. The following release notes apply to the most recent OpenShift GitOps releases on OpenShift Container Platform.
Red Hat OpenShift GitOps is a declarative way to implement continuous deployment for cloud native applications. Red Hat OpenShift GitOps ensures consistency in applications when you deploy them to different clusters in different environments, such as development, staging, and production. Red Hat OpenShift GitOps helps you automate the following tasks:
- Ensure that the clusters have similar states for configuration, monitoring, and storage.
- Recover or recreate clusters from a known state.
- Apply or revert configuration changes to multiple OpenShift Container Platform clusters.
- Associate templated configuration with different environments.
- Promote applications across clusters, from staging to production.
For an overview of Red Hat OpenShift GitOps, see About Red Hat OpenShift GitOps.
For additional information about the OpenShift GitOps lifecycle and supported platforms, refer to the OpenShift Operator Life Cycles and Red Hat OpenShift Container Platform Life Cycle Policy.
1.1. Compatibility and support matrix Copiar o linkLink copiado para a área de transferência!
Some features in this release are currently in Technology Preview. These experimental features are not intended for production use.
In the table, features are marked with the following statuses:
- TP: Technology Preview
- GA: General Availability
- NA: Not Applicable
-
In OpenShift Container Platform 4.13, the
stable
channel has been removed. Before upgrading to OpenShift Container Platform 4.13, if you are already on thestable
channel, choose the appropriate channel and switch to it. - The maintenance support for OpenShift Container Platform 4.12 on IBM Power has ended from 17 July 2024. If you are using Red Hat OpenShift GitOps on OpenShift Container Platform 4.12, upgrade to OpenShift Container Platform 4.13 or later.
GitOps | kam | Argo CD CLI | Helm | Kustomize | Argo CD | Argo Rollouts | Dex | RH SSO | Argo CD Agent | OpenShift Container Platform |
---|---|---|---|---|---|---|---|---|---|---|
1.17.0 | NA | 3.0.12 TP | 3.17.1 GA | 5.6.0 GA | 3.0.12 GA | 1.8.3 GA | 2.41.1 GA | 7.6.0 GA | 0.2.1 TP | 4.12-4.19 |
1.16.0 | NA | 2.14.7 TP | 3.16.4 GA | 5.4.3 GA | 2.14.4 GA | 1.8.0 GA | 2.41.1 GA | 7.6.0 GA | NA | 4.12-4.18 |
1.15.0 | NA | 2.13.1 TP | 3.15.4 GA | 5.4.3 GA | 2.13.1 GA | 1.7.2 GA | 2.41.1 GA | 7.6.0 GA | NA | 4.14-4.17 |
-
Starting from Red Hat OpenShift GitOps 1.15, support is no longer provided for the Red Hat OpenShift GitOps Application Manager command-line interface (CLI),
kam
. - RH SSO is an abbreviation for Red Hat SSO.
1.1.1. Technology Preview features Copiar o linkLink copiado para a área de transferência!
The features mentioned in the following table are currently in Technology Preview (TP). These experimental features are not intended for production use.
Feature | TP in Red Hat OpenShift GitOps versions | GA in Red Hat OpenShift GitOps versions |
---|---|---|
Argo CD Agent | 1.17.0 | NA |
The GitOps | 1.12.0 | NA |
Argo CD application sets in non-control plane namespaces | 1.12.0 | NA |
The | 1.10.0 | NA |
Dynamic scaling of shards | 1.10.0 | NA |
Argo Rollouts | 1.9.0 | 1.13.0 |
ApplicationSet Progressive Rollout Strategy | 1.8.0 | NA |
Multiple sources for an application | 1.8.0 | 1.15.0 |
Argo CD applications in non-control plane namespaces | 1.7.0 | 1.13.0 |
The Red Hat OpenShift GitOps Environments page in the Developer perspective of the OpenShift Container Platform web console | 1.1.0 | NA |
1.2. Release notes for Red Hat OpenShift GitOps 1.17.1 Copiar o linkLink copiado para a área de transferência!
Red Hat OpenShift GitOps 1.17.1 is now available on OpenShift Container Platform 4.12, 4.14, 4.15, 4.16, 4.17, 4.18 and 4.19.
1.2.1. Errata updates Copiar o linkLink copiado para a área de transferência!
1.2.1.1. RHSA-2025:15389 - Red Hat OpenShift GitOps 1.17.1 security update advisory Copiar o linkLink copiado para a área de transferência!
Issued: 2025-09-04
The list of security fixes that are included in this release is documented in the following advisory:
If you have installed the Red Hat OpenShift GitOps Operator in the default namespace, run the following command to view the container images in this release:
oc describe deployment gitops-operator-controller-manager -n openshift-gitops-operator
$ oc describe deployment gitops-operator-controller-manager -n openshift-gitops-operator
1.3. Release notes for Red Hat OpenShift GitOps 1.17.0 Copiar o linkLink copiado para a área de transferência!
Red Hat OpenShift GitOps 1.17.0 is available on OpenShift Container Platform 4.12, 4.14, 4.15, 4.16, 4.17, 4.18, and 4.19.
1.3.1. Errata updates Copiar o linkLink copiado para a área de transferência!
- RHEA-2025:13453 - Red Hat OpenShift GitOps 1.17.0 security update advisory
Issued: 2025-08-07
The list of enhancements that are included in this release are documented in the following advisory:
If you have installed the Red Hat OpenShift GitOps Operator in the default namespace, run the following command to view the container images in this release:
oc describe deployment gitops-operator-controller-manager -n openshift-gitops-operator
$ oc describe deployment gitops-operator-controller-manager -n openshift-gitops-operator
1.3.2. New features Copiar o linkLink copiado para a área de transferência!
- Extended JSON logging support to additional Argo CD components
With this update, the
logFormat: json
setting in the Argo CD custom resource (CR) is supported by theApplicationSet
controller andNotifications
controller. Previously, JSON logging was limited to components such as the API server, repo server, and application controller.NoteRedis and Dex do not support configurable JSON logging and are unaffected by this change.
- Argo CD Agent (Technology Preview)
With this update, a productized container image of the Argo CD Agent is available, along with a custom property in the Argo CD custom resource (CR) to enable the principal component in the hub cluster. For more information, see Overview of the Argo CD Agent.
ImportantThe GitOps Argo CD Agent feature is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.
- Read-only root filesystem for Argo CD components
With this update, core Argo components, such as, Application Controller, Server, Repo Server, Notification Controller, Redis, Dex, and the Argo CD exporter component run with a read-only root filesystem by default. This change enhances security and aligns the operator configuration with upstream Argo CD standards.
1.3.3. Fixed issues Copiar o linkLink copiado para a área de transferência!
- Fixed replica count for
redis-ha-haproxy
to ensure high availability Before this update, an error in configuration caused the
redis-ha-haproxy
deployment to use only one replica. This resulted in access issues with the Redis cache. With this update, the number ofredis-ha-haproxy
replicas matches the High Availability (HA) configuration. Three replicas are created by default, which improves Redis cache availability and resilience.- Fixed invalid Route hostnames for Argo CD webhook server
Before this update, enabling
applicationSet.webhookServer.route
caused an invalid route error due to the default hostname exceeding the Kubernetes label value limit. This issue resulted in application deployment failures. With this update, the default hostname is generated using the Argo CD instance name and namespace, ensuring it stays within the valid length limits. This fix resolves the error and allows successful creation of the webhook server route.- Support added for repeated flags in
extraCommandArgs
Before this update, the
extraCommandArgs
field in the Argo CD custom resource did not support using the same flag multiple times with different values. With this update, repeated flags are correctly handled. Multiple instances of flags can be specified, and all values are included in the controller pod configuration.- Fixed UI error when editing HTTP-based repository credentials
Before this update, you could not edit HTTP repository credentials from the Argo CD web UI. This limited the ability to manage HTTP-based repository configurations through the web interface. With this update, URL validation logic is enhanced, and you can edit HTTP repository credentials in the web UI.
1.3.4. Deprecated and removed features Copiar o linkLink copiado para a área de transferência!
- Deprecation of Keycloak support in Red Hat OpenShift GitOps
In Red Hat OpenShift GitOps 1.17, the support for Keycloak-based authentication is deprecated. When Keycloak is configured for single sign-on (SSO), deprecation warnings appear in the logs. Dex is the default and recommended authentication provider. It integrates with the OpenShift OAuth server and supports authentication based on OpenShift users and groups. You must migrate to Dex-based authentication for continued support. To continue using Keycloak, you must deploy and manage the Red Hat Build of Keycloak (RHBK) instance and manually configure the integration in the Argo CD custom resource.
- Removed support for deprecated
initialRepositories
andrepositoryCredentials
fields In Red Hat OpenShift GitOps 1.17, support for the deprecated
initialRepositories
andrepositoryCredentials
fields is removed. If these fields are used, Argo CD logs a warning indicating their removal. You can add repositories and repository credentials manually by using the Argo CD CLI or the Argo CD dashboard.
1.3.5. Known Issues Copiar o linkLink copiado para a área de transferência!
- SSH-based Git repository connections fail in FIPS mode
There is currently a known issue with clusters in FIPS mode where SSH based git repository connections fail because a non-FIPS-compliant algorithm is used for SSH connections. The repository server pod fails with the
panic: curve25519: internal error: scalarBaseMult was not 32 bytes
error message.Workaround: Use an HTTPS-based Git repository connection instead of SSH on a FIPS-enabled cluster.
1.3.6. Breaking changes Copiar o linkLink copiado para a área de transferência!
- Upgrade to Argo CD 3.0
This release introduces an upgrade to the Argo CD component, transitioning from v2.14 to v3.0. This is a minor upgrade that introduces a list of breaking changes in Argo CD v3.0, with solutions provided in the following section. For more information, see Upgrading Argo CD from v2.0 to v3.0.
- RBAC behavior changes with Argo CD 3.0 and Dex SSO
Argo CD 3.0 introduces a change in RBAC handling when using Dex for single sign-on (SSO). The RBAC system uses the
federated_claims.user_id
field instead of the previously encoded sub claim. This change affects how user identities are evaluated and matched in RBAC policies. You must review and update your RBAC policies to ensure compatibility with Argo CD 3.0. For more information, see Configuring RBAC with Dex SSO Authentication.- Logs RBAC enforcement in Argo CD 3.0
Before this update, users with access to applications could also view logs. With this update, Argo CD 3.0 uses a separate RBAC resource to control log access, which requires explicit permissions. For more information, see Logs RBAC Enforcement.
- Fine-grained RBAC inheritance enabled by default
Starting with Argo CD v3.0, fine-grained RBAC inheritance of applications is disabled, making
update
anddelete
actions apply only to the application resource. To perform these actions on managed resources, you must configure new policies. To maintain the Argo CD v2.0 behavior, theserver.rbac.disableApplicationFineGrainedRBACInheritance
parameter is set tofalse
by default in theargocd-cm
config map. You can enable the new fine-grained RBAC functionality by setting the following configuration in the Argo CD custom resource:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Set
server.rbac.disableApplicationFineGrainedRBACInheritance
totrue
to maintain Argo CD v3.0 behavior.
For more information, see Fine-Grained RBAC for application update and delete sub-resources.
- Backward-compatible changes
To preserve backwards-compatibility with Argo CD 3.0 upgrade, the Red Hat OpenShift GitOps Operator retains some previous behavior by default. You can optionally enable the new behavior for these features.
- Change default resource exclusion configuration
Starting with Argo CD 3.0, the
argocd-cm
config map includes a default configuration for theresource.exclusions
parameter. This configuration excludes resources that are created by controllers but are not managed in Git. The v2 behavior for Argo CD is preserved, and you can continue to use the.spec.resourceExclusions
parameter in the Argo CD CR.- Change default resource tracking method
Starting with Argo CD 3.0, the default behavior for tracking resources changes to use annotation-based tracking instead of label-based tracking. To avoid breaking existing setups that use label-based tracking, the Red Hat OpenShift GitOps Operator continues to use label-based tracking as the default.
- Store resource health status in Redis
Starting with Argo CD 3.0, resource health statuses are stored in Redis instead of in the
Application
CR. This change improves performance by avoiding updates to theApplication
CR. To prevent issues for third-party tools such as Red Hat Advanced Cluster Manager (RHACM) that rely on this status, the Red Hat OpenShift GitOps Operator maintains the previous setting by default. You can override this behavior by setting.controller.resource.health.persist
tofalse
in.spec.extraCommandArgs
in the Argo CD CR.