Creating a tag does not create a version without prerelease-tags

[AlphaYankee]

Hi everyone,

I've used GitVersion 5 for a while and it worked like a charm for what I needed. Now I'm trying to recreate the functionality in GitVersion 6 and it's not working as I expect (and as I understand https://gitversion.net/docs/learn/branching-strategies/githubflow/examples).

I've tried many settings in GitVersion.yml but nothing changes. The following is the basic version:

workflow: GitHubFlow/v1
mode: ContinuousDelivery
branches:
    main:
        label: dev

My expectation is:

• There is a commit tagged as v1.0.8
• I create a new commit. The new version would be 1.0.9-dev.1
• I tag that commit as v1.0.9. The new version would be 1.0.9

It works until the last step. When I tag the commit, it would result in a version 1.0.10-v1-0-9.1+0. The problem seems to be that GitVersion takes the "v1.0.9" not only as a tag but also as the current branch (also tried with "1.0.9" as tag as well).

The relevant variables:

GitVersion_FullBuildMetaData=0.Branch.v1.0.9.Sha.15d677ad161c3b1c93dd79884715e61d7cef36d9
GitVersion_BranchName=v1.0.9
GitVersion_EscapedBranchName=v1-0-9
GitVersion_MajorMinorPatch=1.0.10
GitVersion_SemVer=1.0.10-v1-0-9.1
GitVersion_FullSemVer=1.0.10-v1-0-9.1+0

This is running as a GitLab workflow using the gitversion:6.0.2-alpine.3.18-8.0 container. I tried to find similar issues and discussions but the ones I found don't seem to describe the same issue. So I'm probably just doing something wrong but I have no clue what that is...

[HHobeck]

But your branch is v1.0.9. The only branch configuration which maps to this name here is the unknown branch configuration where the label is set to {BranchName}. From the behavior this is expected. The question is: Why is the v1.0.9 used as a branch?

Maybe related to:

• [BUG]: GitVersion (in Azure Devops) calculating wrong version when building a tag #4015

[AlphaYankee]

So in Forgejo Actions (which is basically a clone of GitHub Actions) this works fine. The log says "Branch from build environment: " and the version is the one defined in the Tag.

I'll upload some log outputs later.

I've been experimenting with Forgejo for a while now, thinking I might migrate from GitLab. So maybe that's the sign that I should go ahead and do it. :)

[AlphaYankee]

I created a new blank project in GitLab that doesn't do anything other than run GitVersion. It only has the master branch and never had any others. This had one tag v1.0.0. I then cloned it to Forgejo.

I made two commits to each repository and finally tagged the second as v1.0.1.

Here are the logs:
GitLab CI - Second Commit
GitLab CI - Tagged as v1.0.1
Forgejo Actions - Second Commit
Forgejo Actions - Tagged as v1.0.1

[HHobeck]

I'm not sure how you are starting the job. Maybe there are multiple option in GitLab to trigger a job:

1. based on a tag
2. based on a commit
3. based on a branch

The problem is for option (1) and (2) the tag or commit can be part of multiply branches. From GitVersion point of view it can be handled automatically if only one branch is involved (like in your example). This logic should be part of the normalization process. Can you reproduce it locally and debug into it to find out where exactly it fails please?

Pull-Requests are welcome.

[asbjornu]

It seems like this is related to #2074, #2456, and #4015. I think what GitVersion needs to do is a ref-check of the checked out commit SHA, and if a tag is found matching the branch name, follow the logic as if it was a tagged commit on the main branch.

[AlphaYankee]

Well all I do is create a tag in the UI, and GitLab will automatically trigger a build. I'm not sure how to reproduce that yet.

What I found is this line of code that says the branch name is in the environment variable CI_COMMIT_REF_NAME. According to the GitLab documentation that variable contains "The branch or tag name for which project is built", so in this case would probably contain the tag.

Maybe something like this would work, I'll test that.

I'll have a deeper look this evening after work. I didn't have time yet to really read through the other topics you referenced, sorry.

[AlphaYankee]

I was able to fix that issue by changing GetCurrentBranch() for the GitLabCi agent to not return the tag in tag pipelines. At least for the use cases I can think of it seems to work fine, and it does mirror the same workaround that is in the GitHubActions agent.

I think this qualifies as a bug, so I'll create a bug report for this for better tracking. I hope that's the correct way. Then I'll create a pull request.

[AlphaYankee]

The issues is #4186 and the PR is #4187