Description of Problem

• ArgoCD is adding the resouceVersion metadata in the last-applied-configuration annotation when it is listed in the .spec.ignoreDifferences

Additional Info

• This behavior can only be triggered when the resourceVersion is listed in the .spec.ignoreDifferences

Problem Reproduction

• The repository https://github.com/gizzi-rh/argocd-resource-version-issue contains a reproducer scenario, it is sufficient to apply the application.yaml and after the initial creation force the Sync in the ArgoCD UI

Reproducibility

• Always in our troubleshooting testing, but in the customer clusters this is not happening always

Prerequisites/Environment

• Openshift 4.12 / 4.16
• Openshift GitOps 1.12.6

Steps to Reproduce

• Apply the application.yaml file contained in https://github.com/gizzi-rh/argocd-resource-version-issue
• Wait for the BuildConfig to be created
• Force a Sync in the ArgoCD UI
• Now the BuildConfig contains the resourceVersion in the last-applied-configuration annotation

Expected Results

• resourceVersion should not be contained in the last-applied-configuration

Actual Results

• resourceVersion is inserted in the last-applied-configuration annotation by ArgoCD
• It is causing `oc apply -f` commands to fail with error:

metadata.resourceVersion: Invalid value: 0x0: must be specified for an update  

• Customer's ArgoCD is experimenting randomly failures with error:

error when patching "/dev/shm/34289001": Operation cannot be fulfilled on buildconfigs.build.openshift.io "build-config-name": the object has been modified; please apply your changes to the latest version and try again  

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.