OpenShift GitOps 1.22 moves promotion and source controls closer to the platform

Red Hat has released OpenShift GitOps 1.22 with a mix of generally available controls for multi-tenant delivery and early-access machinery for promoting rendered manifests between environments. The release is available for OpenShift Container Platform 4.18 through 4.22, according to the 1.22 release notes.

What changed

The supported surface expands in three practical areas. ApplicationSets can now run outside the Argo CD control-plane namespace, letting tenants manage their own declarative application generators with namespace-level isolation. The OpenShift GitOps console plugin is also generally available and exposes Applications, ApplicationSets, AppProjects, ImageUpdater and Rollouts resources inside the OpenShift console. Source Integrity Verification reaches general availability as well, allowing an AppProject to require trusted GnuPG signatures before an application sync proceeds, as Red Hat explains in its release overview.

OpenShift GitOps 1.22 also moves to Argo CD 3.5 and adds Helm 4 support. Its Image Updater gains Cosign-based image-signature verification, automatic masking of sensitive annotations, webhook hardening, NetworkPolicy support and pull-request deduplication. These changes make the release more than a console refresh: they move policy checks nearer to the promotion path.

Promotion is promising, but still preview technology

Two related components arrive as Technology Previews. GitOps Promoter 0.35 uses a PromotionStrategy custom resource to describe environments and gates. Source Hydrator renders Helm or Kustomize sources into full YAML, commits the rendered output to Git and separates manifest generation from deployment. Used together, they offer a reviewable promotion chain in which the exact manifests destined for each environment are visible before synchronization.

That architecture is worth testing, but not treating as a supported production path yet. Red Hat explicitly says Technology Preview features are outside production service-level agreements and may be incomplete. Teams evaluating the pair should keep experiments separate from existing production promotion workflows.

Check the upgrade notes before rollout

Operators using Redis high availability have a concrete upgrade task. Red Hat documents a known issue in which Redis HA pods can enter CrashLoopBackOff after upgrading to 1.22. The stated workaround is to delete the affected Redis server pods one at a time, waiting for each replacement to reach Running before moving to the next.

There is also a Source Hydrator/Image Updater issue: some write-back methods can report success without committing a changed image tag. Red Hat provides a temporary configuration workaround, another reason to keep the hydrator path in evaluation rather than production.

For platform teams, the immediate value is in the generally available tenant and integrity controls. The promotion stack points toward a more auditable delivery model, but its preview status and known issues make staged adoption the sensible course.