Checklist:

• I've searched in the docs and FAQ for my answer: https://bit.ly/argocd-faq.
• I've included steps to reproduce the bug.
• I've pasted the output of argocd version.

Describe the bug

When using tag tracking with a SemVer constraint in an Application source, if using a Gitlab webhook, then tag push events for new tags which match the constraint do not trigger a resync of the Application.

To Reproduce

• Create a code repository in Gitlab with your Kubernetes manifests and add a SemVer tag, eg "1.0.0"
• Create an Application with a target revision set to a version constraint that matches the tag, eg "1.*", and observe that it is synced to "1.0.0".
• Set up a Gitlab webhook which includes tag push events
• Make a change to the code repository and create/push a new tag which matches the source's target revision's constraint, eg "1.1.0"
• Observe that the Application does not resync and remains at "1.0.0" until either you manually sync or after the automated sync interval, at which point it will finally sync to revision "1.1.0".

Expected behavior

The Application should sync to revision "1.1.0" almost immediately after the webhook has fired.

Version

argocd: v2.13.2+dc43124
  BuildDate: 2024-12-11T18:37:15Z
  GitCommit: dc43124058130db9a747d141d86d7c2f4aac7bf9
  GitTreeState: clean
  GoVersion: go1.23.1
  Compiler: gc
  Platform: linux/amd64

Logs

We see acknowledgement that the webhook was received, eg

Received push event repo: <repo>, revision: <pushed tag>, touchedHead: false

but there are no further log messages after that (so, for example, there have been no errors logged).

Suspected Root Cause

I suspect the cause is in the sourceRevisionHasChanged method in util/webhook/webhook.go. For tag push events the revision parameter is coming through as the new tag name, but the method (apart from a bit of edge case handling) is essentially just doing a string equality check between this and the source's target revision. This will obviously fail when the revision is something like 1.1.0 but the target revision is 1.*. Instead, in the event the equality check fails, it ought to additionally try doing a semver constraint check, eg something like the example here.

If this is the underlying cause then the fact we saw this specifically with Gitlab webhooks is likely irrelevant, and I'm guessing the same issue will be seen with other SCM providers' webhooks.