fix: filter git describe to version tags only

[kojiromike]

Checklist

• Either (a) I've created an enhancement proposal and discussed it with the community, (b) this is a bug fix, or (c) this does not need to be in the release notes.
• The title of the PR states what changed and the related issues number (used for the curved release note).
• I've included "Closes argocd admin dashboard failed with failed to get version on v3.3.0 #26220" or "Fixes argocd admin dashboard failed with failed to get version on v3.3.0 #26220" in the description to auto-close the related issue.
• I have signed off all my commits as required by DCO.
• I've written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.

Changes

The stable tag tracks the latest GA release, so it can share a commit with a version tag (e.g. v3.3.0). When both are lightweight tags on the same commit, git describe --exact-match --tags HEAD returns stable (alphabetically first), which gets injected as gitTag via ldflags. The ArgoCD server then rejects the client:

could not parse version from user-agent: argocd-client/stable

This adds --match 'v*' to the git describe invocation so it only considers version-prefixed tags.

Test plan

There is no Makefile test framework in this project. This is a one-line change to a git describe invocation, so here is a CLI reproduction and fix demonstration using the actual ArgoCD repo at v3.3.0 where both stable and v3.3.0 are lightweight tags on the same commit:

$ git tag -l --points-at HEAD
stable
v3.3.0

$ git describe --exact-match --tags HEAD
stable

$ git describe --exact-match --tags --match 'v*' HEAD
v3.3.0

Closes #26220

[bunnyshell]

✅ Preview Environment deployed on Bunnyshell

Component	Endpoints
argocd	https://argocd-ip3epd.bunnyenv.com/
argocd-ttyd	https://argocd-web-cli-ip3epd.bunnyenv.com/

See: Environment Details | Pipeline Logs

Available commands (reply to this comment):

• 🔴 /bns:stop to stop the environment
• 🚀 /bns:deploy to redeploy the environment
• ❌ /bns:delete to remove the environment

[kojiromike]

As an aside, another way to prevent this class of issue would be to use annotated tags for releases (e.g. git tag -a v3.3.0). git describe prefers annotated tags over lightweight ones, so even with stable present on the same commit, it would return the version tag.

From git help tag:

Annotated tags are meant for release while lightweight tags are meant for private or temporary object labels.

The stable tag is a moving pointer — a textbook use case for a lightweight tag. Release tags like v3.3.0 are the textbook use case for annotated tags. Using the conventional tag types for each would have the side effect of making git describe do the right thing without needing --match.

Worth noting: GitHub Releases have a known issue where creating a release automatically creates a lightweight tag unless the tag is pushed first. So any move to annotated tags would need to ensure the tag is pushed before the release is created.

That said, the --match 'v*' fix in this PR is the minimal change and works regardless of tag types.