Description of Problem

• The E2E test 
  `verifying labels and annotations have been removed from template specs of Argo CD components` in 1-043_validate_custom_labels_annotations_test.go is file with the error :-

[FAILED] in [It] - /go/src/github.com/redhat-developer/gitops-operator/test/openshift/e2e/ginkgo/parallel/1-043_validate_custom_labels_annotations_test.go:170 @ 07/31/25 13:16:28.462 << Timeline [FAILED] Expected <string>: custom not to contain substring <string>: custom

When we remove custom labels from the ArgoCD spec (set them to {}), the new code iterates over an empty map, so it doesn't add any new keys, but it also doesn't remove the existing custom keys that should be cleaned up.

Additional Info

• This is happening because of this PR in argocd-operator - https://issues.redhat.com/browse/GITOPS-6285

Problem Reproduction

• deploy argocd operator with labels specified in spec.server.labels ex: 

server:
    labels:
      custom: label
      custom2: server

• kubectl edit argocd <argocdname> -n argocd
• Remove the labels from spec.server or assign empty map
• kubectl describe <any_of_the_server_resource_like_replicaset_server> <name> -n argocd
• We can see that the custom labels are still present and not removed
• If we do the same steps with annotations, annotations are being removed once removed from the CR.

Reproducibility

• Always

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.