Red Hat OpenShift GitOps release notes

Before this update, resource limits were set on the operator container as a recommended practice. However, these limits caused functional issues on clusters with a large number of secrets and config maps because the operator manager, a controller that manages the lifecycle of Argo CD components, required more memory than allowed by these limits. With this update, the resource limits set on the manager container have been removed to minimize the impact on functionality. Efforts are focused to optimize memory consumption for future releases. GITOPS-5665

Before this update, Argo CD could not obtain the appropriate transport layer security (TLS) certificate for Helm Open Container Initiative (OCI) registries when the URL included a path or port number. With this update, a fix is introduced in upstream Argo CD to correctly parse the URL and return a valid certificate. GITOPS-5081

Before this update, you could not log in to the Argo CD web console UI on a Red Hat OpenShift Service on Amazon Web Services (AWS) cluster that includes a GitOps Operator and an Argo CD instance configured with Dex-based SSO, after the cluster resumed from hibernation. The login screen would display an error indicating an invalid redirect Uniform Resource Identifier (URI) in the Dex configuration. This update fixes the issue by ensuring that the correct Dex redirect URL is updated in the Argo CD configuration whenever the Argo CD server route is modified. GITOPS-4358

With this update, users can customize permissions for the Application Controller component in a cluster-scoped Argo CD instance. The Red Hat OpenShift GitOps Operator creates an aggregated cluster role, and you can configure its permissions to combine several cluster roles into a single one. GITOPS-4681

With this update, the following enhancements have been introduced for multi-source application:

With this update, you can extend the repo server storage by mounting persistent volumes. The repo server utilizes the EmptyDir default storage volume, which has limitations and might prove inadequate in scenarios involving numerous repositories, sizable repositories, or repositories containing large manifests. You can mount additional storage on demand by using the .spec.repo.volumes and .spec.repo.volumeMounts fields in the Argo CD custom resource (CR). GITOPS-4646

With this update, you can implement an alternative sharding algorithm that utilizes consistent hashing with bounded loads. The algorithm ensures a uniform distribution of managed clusters across shards while minimizing the need for reshuffling during configuration changes, such as adjustments in the number of managed clusters or shards. GITOPS-3584

With this update, Red Hat OpenShift GitOps provides support for the sidecar and init containers for the Server and Application Controller components. You can configure the sidecar and init containers by using the spec.server.sidecarContainers, spec.controller.sidecarContainers, spec.server.initContainers, and spec.controller.initContainers fields in the Argo CD CR. GITOPS-5010

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: example-argocd
spec:
  server:
    initContainers:
    - name: argocd-init
      image: nginx:latest
    sidecarContainers:
    - name: cmp
      image: busybox

With this update, you can expose Argo CD Application labels on Kubernetes events generated by Argo CD. When events are created for applications that have specific label keys defined in the resource.includeEventLabelKeys field within the argocd-cm config map, the controller adds the matching labels to these events. This enhancement facilitates the filtering and processing of events based on the application labels. To set the resource.includeEventLabelKeys field in a GitOps environment, use the .spec.extraConfig field in the Argo CD CR. The GitOps Operator automatically adds these fields from the .spec.extraConfig field into the argocd-cm config map. GITOPS-3233

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: argocd-sample (1)
  namespace: default (2)
spec:
  extraConfig:
    resource.includeEventLabelKeys: team,env* (3)

With this update, you can verify commit signatures for ApplicationSet CRD created using Git generators. GITOPS-3049

Before this update, users could not execute a rollback for multi-source applications in the Argo CD web UI or CLI. This update fixes the issues, and users can now carry out rollbacks for multi-source applications using the Argo CD web UI or CLI. GITOPS-3996

Before this update, the ApplicationSet Controller role did not include the list and watch permissions for the AppProject resource. As a result, there were errors during the application generation process. This update fixes the issue by granting necessary permissions to the ApplicationSet Controller role. GITOPS-5401

Before this update, Argo CD was unable to synchronize PersistentVolume resources on OpenShift Container Platform v4.16 due to the introduction of the new .status.lastPhaseTransitionTime field in Kubernetes v1.29. This update fixes the issue by modifying the Kubernetes static scheme in Argo CD. GITOPS-5167

Before this update, the Red Hat OpenShift GitOps Operator included a race condition where the OpenShift Service CA created the TLS secret before the default TLS termination policy was set. As a result, the default policy was set as Passthrough instead of Reencrypt. This update fixes this race condition by verifying whether the secret was created by the OpenShift Service CA, ensuring that Reencrypt is used as the correct default policy. GITOPS-4947

Before this update, you could not log in to the Argo CD web console UI after a Red Hat OpenShift Service on AWS cluster, that includes a GitOps Operator and an Argo CD instance configured with Dex-based SSO, resumed from hibernation. The login screen would display an error indicating an invalid redirect URI in the Dex configuration. This update fixes the issue by ensuring that the correct Dex redirect URL is updated in the Argo CD configuration whenever the Argo CD server route is modified. GITOPS-4358

Before this update, adding a self-signed TLS certificate for the ApplicationSet GitLab SCM Provider did not function as intended, as the certificate failed to mount on the required volume. This update fixes the issue by correcting the volume mount path and providing documentation on the usage of this feature. Users are now required to ensure that the config map’s name is argocd-appset-gitlab-scm-tls-certs-cm. GITOPS-4801

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-appset-gitlab-scm-tls-certs-cm (1)
  namespace: test-1-32-appsets-scm-tls-mount (2)
data:
  cert: |
    -----BEGIN certificate-----
    ... (certificate contents) ...
    -----END certificate-----