Story (Required)

• When multiple ArgoCD instances have Applications with same name, it is impossible to differentiate their resources and Applications are in the infinite sync loop.
• ArgoCD supports this scenario, but the setting is not configurable by ArgoCD operator. The feature was introduced in ArgoCD in https://github.com/argoproj/argo-cd/pull/20222.

Background and Approach (Required)

• As the PR https://github.com/argoproj/argo-cd/pull/20222 has been merged in ArgoCD and the feature is available, we would need to update the ArgoCD spec used by argocd-operator.
• We would want to introduce a similar setting to ApplicationInstanceLabelKey.
• Given that there is a another PR https://github.com/argoproj/argo-cd/pull/20327 open in ArgoCD with similar setting, we would want to future proof the spec to handle both the scenarios. Thus, it would be useful to introduce the field as a `map[string] string` instead of string.

     ApplicationTrackingAnnotations map[string]string `json:"applicationTrackingAnnotations,omitempty"` 

• Users can then pass the values like `installationID: "my-unique-id"` in the map which the operator would set in the argocd-cm.

Out of Scope

• <Defines what is not included in this story.>

Dependencies

• <Describes what this story depends on. Dependent stories and EPICs should be linked to the story.>

Acceptance Criteria (Mandatory)

• The code has complete unit test and e2e test coverage of the feature. Discuss with QE folks if anything needs to be added in the test suite
• The Applications tracked by the specific ArgoCD instance are updated with the annotations.
• The build succeeds

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.