Regression: Argo CD reports id of annotated tag, rather than ID of target commit SHA (of annotated tag), via UI and via '.status.sync.revision'

[aenshin-pp]

EDIT: I (@jgwest) have updated bug text with latest investigation plus bug comments.

---

In Git, there are two types of tags: annotated tags and lightweight tags. Annotated tags may have a message/data attached to them, while lightweight tags do not. This means that annotated tags have their own ID (different from the commit SHA), while lightweight tags do not. The ID of the lightweight tag is the same as the target commit SHA. (I'm sure I'm oversimplifying things, see [1] for more details).

As of October 2020, Argo CD would show the commit SHA for annotated tags, rather than the ID of the annotated tag. (The ID of the annotated tag itself isn't especially useful).

However, this behaviour appears to have regressed by #17874 in April 2024 [2], which was subsequently cherry-picked/delivered to v2.11.x, v2.12.x, and v2.13.x. The original, correct behaviour is present in (at least) v2.4.0 to v2.10.0 (I didn't test versions before v2.4.0).

In recent versions, and on master branch, Argo CD will report the id of the annotated tag, and NOT the commit SHA that the ID points to.

This annotated tag ID can be seen in both SYNC STATUS and .status.sync.revision.

[1] https://stackoverflow.com/questions/39754373/why-are-there-two-different-git-commits-for-the-same-tag/39757198#39757198
[2] This was first identified by @blakepettersson (below), and I independently 'git bisect'-ed (not knowing about that original result) and discovered the same commit.

To Reproduce

Automated test:

I wrote an Argo CD E2E test case that reproduces the problem:

• Clone the repo

git clone [email protected]:jgwest/argo-cd
cd argo-cd
git checkout annotated-tag-behaviour-jan-2024
# rebase to master if you wish
make start-e2e

# This will currently fail, as the test is verifying that Argo CD behaviour has regressed: 'revision should not match the annotated tag id'
go test -count=1 -timeout 30s -run ^TestAnnotatedTagInStatusSyncRevision$ github.com/argoproj/argo-cd/v3/test/e2e

Manually:

1. For a GitOps repo of your choice, add an annotated tag:

git clone (your gitops repo)
cd "(your gitops repo)"
git tag -f -a my-annotated-tag -m "my annotated tag"
git push -f && git push -f --tag

2. Create Application targetting that annotated tag via .spec.source.targetRevision.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: application-name
  namespace: argocd
spec:
  destination:
    namespace: argocd
    server: https://kubernetes.default.svc
  project: default
  source:
    path: .
    repoURL: # (... your repo URL ...)
    targetRevision: my-annotated-tag
  syncPolicy:
    automated:
      prune: true
      selfHeal: false

3. View the Application in Argo CD UI. Under SYNC STATUS you will see it points to annotation tag id, not commit SHA.

4. You can also see that Application's .status.sync.revision field likewise shows the annotation tag id, not the commit SHA.

---

Original bug text from reporter:

After updating from v2.4.28 to v2.11.4 in the SYNC STATUS field we start to see hash of annotated tag but not commit.

We have a tool which uses ArgoCD to make decisions during release. Tool is not healthy now since there is no commit hash anymore.

Expected behavior: always show commit hash.

[aenshin-pp]

Might be related to track down the issue:
#4538

[aenshin-pp]

Here is how to reproduce the issue:
#20083 (comment)

thanks to @anandf

[blakepettersson]

@anandf @aenshin-pp I git bisected this, and it seems like the actual culprit is #17874, which got introduced in 2.11-rc3.

[agaudreault]

@aenshin-pp can you update the description of the issue and add screenshots. I do not understand how this differs from #20083 and it is hard to know if it is resolve or not, as the reproduction steps are the one of the other resolved issues.

[aenshin-pp]

@agaudreault this is still unresolved. Reproduction steps are in this comment
#20083 (comment)

It is located in another issue by mistake. Please read only the comment and ignore other comments and issue 20083 itself.

[jgwest]

I've updated the bug text with initial investigation results.

We're also seeing a (likely) related behaviour, in that selfHealing is occurring in cases where it shouldn't when targeting an annotated tag. I've opened a new bug for this: #21548