Understanding commit count source in 5.11.1

[carmine-ianniello-deltatre]

Hello,

we are working with Azure DevOps on-premise agent and with a mono branch repository.
That means that we have our repo with the main branch and create a new branch from there with a feature/fix/whatever branch name, we create a PR and then we merge this feature into the main. So, we don't have any develop branch, or another branch either

At the end of the story, we basically have the main branch always upgraded.
With this scenario, we are continuous delivery code on the DEV environment, and we are using the GitVersion tool (5.11.1) with an alpha tag.
All our images are so tagged with 0.1.0-alpha0001 and so on.

When we are ready to go in the upper environments, we are going to manually tag our main branch (generally at the end of a sprint).
So let's say we created the 1.0.0-rc tag on our main branch.
We now release our new image into the upper env, which is going to take only images with -rc tag.

After that, we keep working on the main branch as always (new branch, PR, merge), if we need to fix something on a specific version, we checkout onto a specific tag, fix that version, and merge that fix again onto main to have the next release with the fix too.

So far so good.

From what I noticed, after we manually tag the main branch, the commit count source from git version, starts again from zero, taking into consideration that the manual tag applied.
What I mean is that, after our release candidate (1.0.1-rc), the next alpha version is going to start from 1.0.1 and not from 0.1.0.
So now all our next images for the dev env will be tagged as 1.0.1-alpha0001, 0002 and so on.

But after a while, we are going to tag our main branch again, with another tag but with the same semantic version.
So our main branch is going to have:

• 1 tag for rc like: 1.0.0-rc
• and another one like: 1.0.0-stable.

We are using this method because is the way we are going to "separate" the image for each environment:
one env is going to have only rc tag, and another is only stable tag, the dev env is always going to have only the alpha tag autogenerate from the GitVersion.

The problem is that each time we are going to tag our main branch, the counting start from zero, leading to a have again the same 1.0.0-alpha0001, 0002 for the dev env.
Is there a way to tell to GitVersion to keep in consideration also the tag that we are putting after the semantic version?
Or a way to tell to keep incrementing the alpha tag?

Thanks!

This is our gitversion file:

     branches:
        main:
          regex: ^master$|^main$
          mode: ContinuousDeployment
          tag: alpha
          increment: Minor
          prevent-increment-of-merged-branch-version: false
          track-merge-target: true
          source-branches: [ ]
          tracks-release-branches: true
          is-release-branch: false
          is-mainline: true
          pre-release-weight: 0

[HHobeck]

Hi there.

Have you seen the improvement issue #3041 already? I'm honest: It's not clear for me what your workflow is and what you trying to achieve. Please simplify your scenario and provide an integration test targeting version 6.x (main branch).

Thank you very much.

[carmine-ianniello-deltatre]

Hello @HHobeck I'll try to explain myself better.
In azure devops we have a repository with a main branch.
The pipeline to build the code inside this repos, in triggered when we manually tag the main branch.

This manual tag is done at the end of every sprint. What we notice is that, once we tag our main branch, the commit count of GitVersion starts from zero for the next images tagged automatically via the GitVersion tool.

As you can see from the images, we first tag with 2.0.1-rc, the commit source start again from zero, and we arrived at 2.0.1-alpha0035.
If we tag again the main branch with the 2.0.1-stable version, the count source starts again from zero leading to the same tags for different images.

What I'm trying to say and achieve, is that the 2.0.1-rc and 2.0.1-stable have the same base code basically, but I would like to have GitVersion taking in consideration for the next alpha tags, not only the semantic version (2.0.1) but also my tag (rc or stable).

So in the end, if I tag my branch with 2.0.2-rc, the next alpha version will be something like 2.0.2-alpha0001, but if I tag again with the 2.0.2-stable, the next alpha version should be something like 2.0.2-beta0001, or 2.0.2-alpha002.

So my question is: is there a way to avoid commit count source reset? Or, is there a flag to tell GitVersion if spot a tag with a particular prefix, to do particular stuff?
(if -stable then tag with beta)

I hope this can be helpful.

[HHobeck]

I cannot answer your question because I'm only familiar with the code base and behavior of the upcomming release of git-version 6.x. If you want my opinion: I don't think there is an option in version 5.11.1.

This manual tag is done at the end of every sprint. What we notice is that, once we tag our main branch, the commit count of GitVersion starts from zero for the next images tagged automatically via the GitVersion tool.

You are talking about commit count source but the number you are meant is the pre-release-number. Isn't it?

Please take a look to the following issue: [Bug] Consider pre-release tags only when they matching with the label name on branch

[Test]
public void Just_A_Test()
{
    var configuration = GitHubFlowConfigurationBuilder.New
        .WithLabel(null)
        .WithBranch("main", branchBuilder => branchBuilder
            .WithVersioningMode(VersioningMode.ContinuousDeployment)
            .WithLabel("rc").WithIncrement(IncrementStrategy.Patch)
        ).Build();

    using var fixture = new EmptyRepositoryFixture("main");

    fixture.MakeATaggedCommit("1.0.0");
    fixture.MakeACommit();

    // ✅ succeeds as expected
    fixture.AssertFullSemver("1.0.1-rc.1", configuration);

    fixture.ApplyTag("1.0.1-rc.1");

    // ✅ succeeds as expected
    fixture.AssertFullSemver("1.0.1-rc.1", configuration);

    fixture.MakeACommit();

    // ✅ succeeds as expected
    fixture.AssertFullSemver("1.0.1-rc.2", configuration);

    fixture.MakeACommit();

    // ✅ succeeds as expected
    fixture.AssertFullSemver("1.0.1-rc.3", configuration);

    fixture.ApplyTag("1.0.1-stable");

    // ✅ succeeds as expected
    fixture.AssertFullSemver("1.0.1-rc.3", configuration); // <<---- Still rc.3

    fixture.MakeACommit();

    // ✅ succeeds as expected
    fixture.AssertFullSemver("1.0.1-rc.4", configuration);
}

[carmine-ianniello-deltatre]

You are talking about commit count source but the number you meant is the pre-release-number. Isn't it?

yes, this number is created by the GitVersion itself, and its incrementation is given by the commit on the repo.
My question is:
what if I don't have multiple branch repositories?
what if tag my main branch with the same tag but with a different suffix? (2.0.1-rc and 2.0.1-stable)
why gitversion is not taking in consideration my suffix? Or how I can tell it to do so?

[HHobeck]

I'm moving this to the discussion section because it seems to be not an issue report.