Issue

We have a customer who has deployed a application with "SyncPolicy" automated and "prune: true" and "Self-Healing" is disabled by default.

Customer is trying to make the manual changes to the deployment (updating replica count, increasing resource limits) on cluster.

But these changes are getting reverted back. Ideally this should not get reverted and application should not get auto synced. As Self-Healing disabled, changes that are made to the live cluster should not trigger automated sync.

This works fine with git and bitcuket repos and changes does not get reverted and application does not get auto-synced but It does not work with the Azure DevOps (ADO) repos.

Edit by jgwest: It's not specific to ADO, I'm able to reproduce on GitHub (or locally) using annotated tags.

Impact

This makes it difficult to work on configuration changes and test them manually before we add them to our GitOps repository.

Environment

OCP Version: 4.14
Red Hat OpenShift GitOps Operator : 1.14 and 1.15

Findings:

In customers repository, They use Git tags, and they use those in the ArgoCD targetRevision.

On checking, It appears to be a issue with the tag, It happens when a tag is created with additional information, like a description and annotations.

We didn't see this issue with Bitbucket because the Bitbucket Web UI creates tags without any annotations.

This works fine with a lightweight git tag without additional information, like a description and annotations. But does not handle annotated Git tags correctly.
Seems it gets confused by the two different Git commit hashes that are associated with each annotated tag.

In the ADO Web UI, the tag description is a mandatory field when creating a tag. So every time they are making any changes to the resource on live cluster its getting reverted.

Workaround

This works fine with git and bitbukcet repos but not with the Azure DevOps (ADO) repos. (EDIT by jgwest : As above, not an ADO-specific issue.)
On further checking on this, We found that this works fine with the applications where ADO repo has Only one branch and no tags.

jgwest opened this upstream Argo CD bug describing the behaviour and likely cause:

https://github.com/argoproj/argo-cd/issues/21548