Description of Problem

The gitopsservice controller, which creates the default openshift-gitops instance, still uses the v1alpha1 ArgoCD CRD. In most cases this is fine because the conversion webhook transparently upgrades objects to v1beta1. However, some users may see confusing or unexpected behavior in edge cases.

Additional Info

Slack thread: https://redhat-internal.slack.com/archives/CMP95ST2N/p1758578100485629 

AI Summary:

• Problem: GitOps service CR deploys with openshift GitOps operator, competing with Argo application to manage argo cr.
• Removing GitOpsService CR is not supported.
• GitOpsService CR creates openshift-gitops instance; does not interfere with changes via openshift-gitops ArgoCD CR.
• GitOpsService CR is recreated when operator container restarts after manual deletion.
• Bug identified: gitopsservice tries to apply v1alpha1 instead of v1beta1.
• Code line identified as potentially confirming v1alpha1 application.

  Problem Reproduction

• <How do we reproduce the problem?>

Reproducibility

• <Always/Intermittent/Only Once>

Prerequisites/Environment

• <OpenShift, managed service (e.g., ROSA, ARO), operators, layered product, and other software versions, build details>

Steps to Reproduce

• ...

Expected Results

• ...

Actual Results

• ...

Problem Analysis

• <Completed by engineering team as part of the triage/refinement process>

Root Cause

• <What is the root cause of the problem? Or, why is it not a bug?>

Workaround (If Possible)

• <Are there any workarounds we can provide to the customers?>

Fix Approaches

• <If we decide to fix this bug, how will we do it?>

Acceptance Criteria

• ...

Definition of Done

• Code Complete:
  • All code has been written, reviewed, and approved.
• Tested:
  • Unit tests have been written and passed.
  • Ensure code coverage is not reduced with the changes.
  • Integration tests have been automated.
  • System tests have been conducted, and all critical bugs have been fixed.
  • Tested and merged on OpenShift either upstream or downstream on a local build.
• Documentation:
  • User documentation or release notes have been written (if applicable).
• Build:
  • Code has been successfully built and integrated into the main repository / project.
  • Midstream changes (if applicable) are done, reviewed, approved and merged.
• Review:
  • Code has been peer-reviewed and meets coding standards.
  • All acceptance criteria defined in the user story have been met.
  • Tested by reviewer on OpenShift.
• Deployment:
  • The feature has been deployed on OpenShift cluster for testing.