Story (Required)

NOTE: This feature came as a contribution from community. Creating this Jira to track it internally for downstream validation during release. 

Provide ability to add custom labels and annotations on the server, repo, applicationset-controller, and application-controller pods. This feature is particularly useful for observability purpose by external systems, which primarily require annotating or labeling resources for monitoring.

More details:

• https://github.com/argoproj-labs/argocd-operator/issues/637
• https://github.com/argoproj-labs/argocd-operator/issues/1530 
• https://github.com/argoproj-labs/argocd-operator/issues/861 

Background and Approach (Required)

Operator removes any labels/annotations added directly onto the Argo CD component pods during reconciliation. To support labels and annotations on pods, introduce new fields in ArgoCD CR to define custom labels and annotations for pods.

Example:

apiVersion: argoproj.io/v1beta1
kind: ArgoCD
metadata:
  name: argocd-sample
spec:
  server:
    labels:
      custom: label
      custom2: server
    annotations:
      custom: annotation
      custom2: server
  repo:
    labels:
      custom: label
      custom2: repo
    annotations:
      custom: annotation
      custom2: repo 

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)

• <Describe edge cases to consider when implementing the story and defining tests.>
• <Provides a required and minimum list of acceptance tests for this story. More is expected as the engineer implements this story.>

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.