I am having a job that has two steps:

• Checkout code
• Execute commands: This does a git fetch --tags in order to be able to calculate a build version based on git tags

This works if I run the job manually but it fails if I trigger it via tag creation.

I am using the macOS Tool "Fork" which uses annotated tags in order to store a message along with the tag. On console that would be

git tag 1.0.0 e7b9e6a3517f9dbb68073d613768fef02742eb25 --annotate -m "The first release as of 2023"

However doing so creates a tag object in git in order to store the tag message on the tag itself. That means in .git/refs/tags/1.0.0 the hash of the tag object is stored and not the hash e7b9e6a3517f9dbb68073d613768fef02742eb25 of the commit being tagged. So for example 09df3af02d5fe74b46e776b2bc4f9ffc863dfb4e is stored and git show 09df3af02d5fe74b46e776b2bc4f9ffc863dfb4e would output the tag information, including the tag message, as well as the linked commit information.

I have looked into the code of OneDev and the Checkout step roughly does

git init .
git fetch e7b9e6a3517f9dbb68073d613768fef02742eb25
git remote add origin <clone url>
git checkout e7b9e6a3517f9dbb68073d613768fef02742eb25
git update-ref refs/tags/1.0.0 e7b9e6a3517f9dbb68073d613768fef02742eb25

So it always uses the commit being tagged. Now technically everything seems ok. git log --oneline shows correct history and git tag shows tag 1.0.0. However if I now do git fetch --tags I get a git error saying that the fetched tag 1.0.0 would clobber with an existing tag. The reason is that the fetched tag has the hash of the tag object instead of the hash of the tagged commit.

So OneDev should call update-ref with the hash of the tag object instead of the hash of the commit being tagged if the tag is an annotated tag.

I think as a workaround I could use git fetch --tags --force which will override local tags, but OneDev should setup the checked out repository correctly.