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 Copy linkLink copied to clipboard!
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 | Argo CD CLI | Helm | Kustomize | Argo CD | Argo Rollouts | Dex | RH SSO | Argo CD Agent | OpenShift Container Platform |
---|---|---|---|---|---|---|---|---|---|
1.18.0 | 3.1.5 TP | 3.18.4 GA | 5.7.0 GA | 3.1.6 GA | 1.8.3 GA | 2.43.0 GA | NA | 0.4.1 TP | 4.14, 4.16-4.19 |
1.17.0 | 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 | 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 |
- Starting from Red Hat OpenShift GitOps 1.18, support is no longer provided for Keycloak-based authentication. As an alternative, you can migrate to Dex or configure a self-managed Red Hat Build of Keycloak (RHBK) instance.
-
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 Copy linkLink copied to clipboard!
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.18.0 Copy linkLink copied to clipboard!
Red Hat OpenShift GitOps 1.18.0 is available on OpenShift Container Platform 4.14, 4.16, 4.17, 4.18, and 4.19.
1.2.1. Errata updates Copy linkLink copied to clipboard!
- RHEA-2025:16586 - Red Hat OpenShift GitOps 1.18.0 security update advisory
Issued: 2025-09-24
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.2.2. New features Copy linkLink copied to clipboard!
- Support for defining local users in the Argo CD custom resource
With this update, you can define local users in the Argo CD custom resource (CR) by using the GitOps Operator. The GitOps Operator can also automatically generate Argo CD API tokens for these users. For more information about managing and configuring local users in Argo CD, see "Managing local users in Argo CD" in the Additional Resources section.
- Support for tenant-managed namespaces with the
NamespaceManagement
CR With this update, support is provided for the
NamespaceManagement
CR, which enables tenants to allow Argo CD management of their own namespaces without requiring cluster-admin access. Cluster administrators must first enable the feature in the Red Hat OpenShift GitOpsSubscription
resource and specify the allowed namespaces in the Argo CD CR. When a tenant creates aNamespaceManagement
CR in their namespace, the Red Hat OpenShift GitOps Operator automatically configures the requiredRole
andRoleBinding
resources and updates Argo CD’s managed namespace list. TheNamespaceManagement
CR improves security by reducing the need for elevated permissions, simplifies setup through automatic configuration, and ensures clean resource management by cleaning up configurations when the feature is disabled.- Support for injecting additional volumes into the Dex container
With this update, the Red Hat OpenShift GitOps Operator supports injecting additional volumes and volume mounts into the Dex container through the Argo CD CR. This enables advanced use cases such as mounting custom certificates, configuration fragments, or identity provider metadata required by Dex.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow For more information, see "Additional Volume Mounts for Dex Container" in the Additional resources section.
- Control automated synchronization with the
enabled
field With this update, the Red Hat OpenShift GitOps Operator introduces a new boolean field named
enabled
under.spec.syncPolicy.automated
in theApplication
CR. The field gives users explicit control over enabling or disabling automated synchronization. The following key improvements are included in this feature:-
A new
Enabled
checkbox in theApplication Create
andApplication Summary
panels. -
Auto-sync can be enabled or disabled independently of
prune
andselfHeal
. -
Defaults to
true
for backward compatibility. When set to
false
, auto-sync is explicitly disabled even if the automated block exists.Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteIf the
enabled
field is not set, automated synchronization defaults toenabled
to maintain backward compatibility.
-
A new
- Granular control of banner display in the Argo CD UI
With this update, the Red Hat OpenShift GitOps Operator adds support for the permanent and position properties within the
.spec.banner
field in the Argo CD CR. The following options provide more granular control over how banners are displayed in the Argo CD web UI.-
.spec.banner.permanent
: A boolean field, when set totrue
, prevents users from dismissing the banner. .spec.banner.position
: A string field that specifies where the banner is displayed. Supported values aretop
andbottom
.spec: banner: content: "Maintenance in progress" permanent: true position: top
spec: banner: content: "Maintenance in progress" permanent: true position: top
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
- Upgraded Kubernetes and Argo CD dependencies
With this update, the Red Hat OpenShift GitOps Operator upgrades the Kubernetes and Argo CD dependencies used in the GitOps backend. The newer versions address vulnerability alerts previously flagged by CVE scanners in older dependency versions, ensuring alignment with more recent and secure libraries.
- Default resource exclusions in Red Hat OpenShift GitOps
With this update, the Red Hat OpenShift GitOps Operator introduces a default
resource.exclusions
configuration, consistent with upstream Argo CD. By default, the Argo CD Application Controller excludes well-known, auto-generated, or frequently changing resources that are created by controllers. This behavior reduces unnecessary load. You can override or customize these exclusions in the Argo CD configuration if needed.
1.2.3. Fixed issues Copy linkLink copied to clipboard!
- Fixed misleading error logs when the
ConsoleLink
resource is disabled Before this update, when the
DISABLE_DEFAULT_ARGOCD_CONSOLELINK
variable was set totrue
and theConsoleLink
resource did not exist, the Red Hat OpenShift GitOps Operator logged an error even though functionality was not affected. With this update, the Red Hat OpenShift GitOps Operator does not log an error in this scenario, preventing misleading error messages.- Fixed stale application controller permissions for custom resources
Before this update, the Red Hat OpenShift GitOps Operator did not reconcile the
Application
controller role to manage custom resources introduced by new Operators. With this update, the Red Hat OpenShift GitOps Operator watches the admin cluster role and automatically updates the Application controller role with the required permissions. As a result, theApplication
controller can now manage custom resources in a managed namespace.
1.2.4. Known issues Copy linkLink copied to clipboard!
- Sync triggers incorrectly on Bitbucket mono-repositories with uppercase letters in names
There is currently a known issue affecting webhook-triggered syncs on Bitbucket mono-repositories that use the
manifest-generate-paths
annotation and have repository names containing uppercase letters. An underlying API call to detect file changes fails for these repositories, causing the system to ignore the specified paths. As a result, a sync operation is triggered on every change instead of only when the files defined in the annotation change.Workaround: Ensure that your Bitbucket repository name only uses lowercase letters to enable path-based sync triggering.
1.2.5. Deprecated and removed features Copy linkLink copied to clipboard!
- Removed support for Keycloak in Red Hat OpenShift GitOps
In Red Hat OpenShift GitOps 1.18, the support for Keycloak-based authentication is removed. As an alternative, you can migrate to Dex or configure a self-managed Red Hat Build of Keycloak (RHBK) instance. Dex is the default authentication provider in Red Hat OpenShift GitOps. It integrates with the OpenShift OAuth server, enabling users to log in to Argo CD with their existing OpenShift users and groups. For more information, see "Configuring SSO for Argo CD using Dex" in the Additional resources section. If you still want to use 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. For more information about configuring Argo CD with keycloak, see the upstream documentation for "Keycloak" in the Additional resources section.