Epic Goal

• Provide native support of latest features, improvements and bug fixes available in upstream Argo CD v3.1 version to be available as part of OpenShift GitOps product, 
• newest features, bug fixes and enhancements added as part of Argo CD v3.1 must be made available for OpenShift GitOps customers.

Why is this important?

For every y-stream release of OpenShift GitOps, we uptake the latest version of upstream Argo CD. For 1.18.0 release, we expect to package the upstream Argo CD v3.1.0 which contains several new features like OCI support, promotor pattern, Bitbucket Mono repo support etc. which many OpenShift GitOps customers are interested as well. If any native support needs to be provided in Argo CD Operator in order to improve the user experience, those needs to be done as part of this epic too.

Some of the major features included as part of Argo CD v3.1 are as follows:

1. Helm upgrade to 3.18.3
2. Kustomize upgrade to 5.7.0
3. OCI artifact support (Beta)
4. Bitbucket support for mono-repos (RFE) (GITOPS-5431)
5. Source Hydrator/Promotor feature.
6. Field for explicitly setting automatedSync in Application. (RFE) 
7. Plugin support for Argo CD CLI
8. UI changes for ApplicationSet progressive syncs
9. Newly added Health Checks and resource customizations.

Scenarios

1. Ensure that the build time dependencies like go toolset, 3rd party dependencies like helm, kustomize redis, dex etc required for building and running Argo CD is made available in the Konflux build systems.
2. Ensure that the latest version of CRDs are packaged along with OpenShift GitOps product bundle.
3. Identify any backwards incompatible changes between the previous release and the current release i.e Argo CD 3.0 and Argo CD 3.1 and prepare and an action plan to mitigate the impact. Add stories for each such backwards incompatible changes.
4. E2E tests for upstream Argo CD v3.1 must pass with the downstream build of OpenShift GitOps 1.18.0
5. Ensure that the documentation for the latest features are available as part of the OpenShift GitOps product documentation.

Acceptance Criteria (Mandatory)

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. ...

Previous Work (Optional):

1. …

Open questions::

1. …

Done Checklist

• Acceptance criteria are met
• Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
• User Journey automation is delivered
• Support and SRE teams are provided with enough skills to support the feature in production environment