[Bug] Incrementing steps does not occur when I expect them

[Tiraflo]

Dear all,

First of all, I would like to apologize if the following description comes from a misunderstanding.

Describe the bug

1. Using the below yml configuration (with the continuous deployment mode), no increment is applied after tagging when tag has format "M.m.p-ciCommitsSinceVersionSourcePadded" (this behaviour suits my needs but I don't want to take advantage of it if this really a bug).
   

2. If I add a bump message (excepted the major bump message) or/and a next-version value in the configuration file, it's not applied (+semver: patch in the below image).
   
   next-version: 1.2.1

Expected Behavior

1. Since the HighestTagBaseVersionStrategy strategy is used, ShouldIncrement is true and I expect that GitVersion returns 1.3.0-ci0001 (because increment: Minor for the master branch).

2. At least, I would expect next-version to be prior to the increment field (or somehow it overrides it) so that the next GitVersion output would be 1.2.1-ci0001.
   Does GitVersion select the highest tag among all the strategies ?

Actual Behavior

1. GitVersion returns 1.2.0-ci0002 (it's fine for me because I would like automated tagging from the build server but I'm a bit puzzled).

2. GitVersion returns 1.3.0-ci0001.

Steps to Reproduce

• Create a Git repo (git init) without any particular flow (only one branch master). All of this can be done locally without remote.
• Use the below GitVersion.yml file
• Create dummy commits and simulate the automated tagging behaviour (use the NuGetVersionV2 output when simulating a successful build)
• (Optional) Simulate some human decisions by creating release tags (format "M.m.p")
• See an example in section Environment

Context

We are a small team of three persons working on a railway simulator using Unity3D.
Because Unity introduced packages (npm-like) recently, we think it's time to have a modular approach to ease maintenance and progress. Going a bit further, thoses packages will use .Net Standard libraries (assemblies) for multiple reasons: cross-platform, decoupling logic from UI (graphical engine) and so on...
Based on this vision and on our small number (each one almost responsible for a dedicated task during a given period), I consider that using the centralized Git flow (a single branch, the most basic one) is still applicable for most cases (for now).

Because GitVersion is popular and still maintained regarding MSBuild (from my short experience, many MSBuild tasks projects are not maintained anymore and do not work properly those days ; therefore I'm planning to use Nuke but I like thinking in a standard way as well for fallback purposes).

As a result, I'm trying to find out a proper GitVersion strategy/configuration for a centralized workflow.
I wish to use a build server in a way that successful builds would lead to a new tag. Is this approach still valuable today? What else could I do to get a similar result?
So far, in my opinion, documentation gives freedom to interpretation regarding the way GitVersion should handle the build number coming from a build server (and that's pretty normal).

From my perspective, section Incrementing per commit and its linked blog post are the most valuable info for people looking for automated continuous building (whatever it's continuous integration/delivery/deployment). That's why I chose the continuous deployment mode even if we will only do continuous integration for starters (as result, I get the impression mode names are not appropriate and a mode is not picked up according to the adopted continuous approach)

Environment

Windows 10
GitVersion.Portable v5.3.4
GitVersion.yml:

#next-version: 1.1.1
mode: ContinuousDeployment
branches: 
  master:
    regex: ^master
    increment: Minor
ignore:
  sha: []
merge-message-formats: {}

Test project history (local Git repo):

Tags with format "M.m.p-ciCommitsSinceVersionSourcePadded" would be tags automatically created by the build server in case of success while building (& testing). It uses the NugetVersionV2 GitVersion output.
Tags with format "M.m.p" are tags manually created (corresponding to actual releases).

[Tiraflo]

The second case actually behaves properly, as stated (https://gitversion.net/docs/more-info/how-it-works):

3. The highest base version is selected, using that base version as the new version is calculated.

Regarding the first issue, I can assume it works properly as well but in my opinion, it's not mentioned the "Incrementing per commit" approach overrides the increment rules when tagging. Once more, I found a pretty clear statement but I cannot be 100% sure it matches my usage (https://gitversion.net/docs/reference/versioning-modes/continuous-deployment):

The default behavior for v3 and how v1 & 2 worked was that the version only incremented after a tag, which signified a release. In v3 you can simply switch the default mode in the configuration from ContinuousDelivery to ContinuousDeployment and the version will then increment each commit, giving you the features of GitVersion with continuous deployment

Regards.

[asbjornu]

I'm sorry, but I'm having a hard time understanding exactly what it is you expect. Would it be possible for you to submit a pull request with a RepositoryFixture test that reproduces your expectations?

[Tiraflo]

I would be glad to reproduce my issue but how should I proceed ? I don't know what a RepositoryFixture test is.

My expectations are based on my own understanding of GitVersion docs. They are not what I would like or how it should behave.

Let me try to put my words in a different way.

The patch/minor increment done after a tag is described as a general behaviour, not something specific to the continuous delivery mode:

(https://gitversion.net/docs/configuration)

increment

The part of the SemVer to increment when GitVersion detects it needs to be increased, such as for commits after a tag: Major, Minor, Patch, None.

(https://gitversion.net/docs/more-info/version-increments)

Tagging commit

By tagging a commit, GitVersion will use that tag for the version of that commit, then increment the next commit automatically based on the increment rules for that branch (some branches bump patch, some minor).

Therefore I was/am expecting that, when choosing the continuous deployment mode, each commit will increment the pre-release tag but once a (git) tag is applied (whatever the tag format is i.e. either "M.m.p-ciCommitsSinceVersionSourcePadded" for instance 1.1.0-ci0003, either "M.m.p" for instance 1.2.0), then the bump process explained in the quotes overrides the pre-release tag increment.
Here is an example:
The increment parameter is set to patch
We have a commit tagged with the following : 1.2.0
3 commits later, GitVersion returns 1.2.1-ci0003
2 cases:

1. If this latter commit is tagged as 1.2.1, the next commit will have 1.2.2-ci0001
2. If this latter commit is tagged as 1.2.1-ci0003,
   • the commit after will have 1.2.1-ci0004 (actual behaviour)
   • the commit after will have 1.2.2-ci0001 (expected behaviour)

The actual behaviour of the second statement suits me well but also disturbs me because, according to me, documentation does not explain what happens when a git tag contains a pre-release tag (which is the case when using a build server that automatically tags successful builds).

As of today, I think my expected behaviour is wrong and some examples in the doc can argue that the actual behaviour is the proper expected one:

(https://gitversion.net/docs/more-info/how-it-works)

If the base version corresponds to the HighestReachableTag strategy then it shows how is the version incremented for the next commits when a git tag contains a pre-release tag.

Is it a bit more understandable ? Sorry if my words are not very clear.

[asbjornu]

When you created this very bug report, it contained the following information:

## Steps to Reproduce
<!--
If you are able to write your bug or scenario up as a `RepositoryFixture` test
and submit a pull-request with it, it is going to increase the likelyhood of
the bug being fixed.

It will both make it easier to understand what you are trying to achieve, how
GitVersion deviates from this expectation and to start debugging the problem. It
will also make it easier for you to fix the problem yourself. Please look at the
following example for how such a test can look like:

https://github.com/GitTools/GitVersion/blob/251645f08802ea9dc401d5b2f2d681e8f8adf626/src/GitVersionCore.Tests/IntegrationTests/MasterScenarios.cs#L13-L32

Otherwise, please provide a link to a live example, or an unambiguous set of
steps to reproduce this bug.
-->

Please read this information. If we get a RepositoryFixture test, it's going to help immensely to understand what it is you are expecting GitVersion to do.

[asbjornu]

Is this in any way related to #2340, perhaps?

[HHobeck]

From my perspective, section Incrementing per commit and its linked blog post are the most valuable info for people looking for automated continuous building (whatever it's continuous integration/delivery/deployment). That's why I chose the continuous deployment mode even if we will only do continuous integration for starters (as result, I get the impression mode names are not appropriate and a mode is not picked up according to the adopted continuous approach)

Two remarks/questions from my side:

1. The second link you have mentioned is a block post of Xavier Decoster from April 29, 2013 where he says, that the ordering is problematic if you use just one digit. I'm using the revision number for nuget package versioning and it works very well. ;)
   

2. What do you mean with: as result, I get the impression mode names are not appropriate? I'm also thinking that we need to consolidate it but not sure how to do it right. Plesae see this issue [Improvement] Replacing the mainline version mode with the continuous deployment mode #3308. Which mode you would like to see?

[HHobeck]

If I take your first scenario and execute the following integration test on the main branch then the behavior of GitVersion is like I would expecting it. Why would you expect to increase the minor number after a pre-release? It makes no sense. Please see also the bug fix #3438.

[Test]
public void Scenario1()
{
    var configuration = GitFlowConfigurationBuilder.New
        .WithVersioningMode(VersioningMode.ContinuousDeployment)
        .WithBranch("main", builder => builder
            .WithIncrement(IncrementStrategy.Minor).WithLabel("ci")
        ).Build();

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

    fixture.MakeACommit();
    fixture.MakeACommit();

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

    fixture.MakeATaggedCommit("0.1.0-ci.3");

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

    fixture.MakeACommit();

    // ✅ succeeds as expected
    fixture.AssertFullSemver("0.1.0-ci.4", configuration);

    fixture.ApplyTag("0.1.0");

    // ✅ succeeds as expected
    fixture.AssertFullSemver("0.1.0", configuration);

    fixture.MakeACommit();

    // ✅ succeeds as expected
    fixture.AssertFullSemver("0.2.0-ci.1", configuration);
}

[HHobeck]

The behavior in your second scenario is also correct. Please see the following integration test:

[Test]
public void Scenario2()
{
    var configuration = GitFlowConfigurationBuilder.New
        .WithVersioningMode(VersioningMode.ContinuousDeployment)
        .WithNextVersion("0.2.1")
        .WithBranch("main", builder => builder
            .WithIncrement(IncrementStrategy.Minor).WithLabel("ci")
        )
        .Build();

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

    fixture.MakeATaggedCommit("0.2.0");

    // ✅ succeeds as expected
    fixture.AssertFullSemver("0.2.0", configuration);

    fixture.MakeACommit();

    // ✅ succeeds as expected
    fixture.AssertFullSemver("0.3.0-ci.1", configuration);
}

To understand in which business use case the next-version might be good for I would like to point you to #3177 (comment):

[..] Now this is the point where you have already communicate with the business and told the tester that they can expect the feature/A and B in the version 1.0.0. Or you have technical or regulatory constraints who knows!? The point here is that you need to cancel the hole release and skip this number 1.0.0. You are deleting the release branch or even the develop branch and start again integrating the feature/A and feature/C into a new alpha version with the number 1.1.0 (or even 1.2.0 if the version 1.1.0 is burned too) and start the hole process from beginning. You could say but if I delete the release branch the next version will be just the 1.0.0 in the develop branch. Yes you are right but exactly for this use case the next version configuration or bump messages are good for in GitVersion.

Cheers

[arturcic]

🎉 This issue has been resolved in version 6.0.0-beta.2 🎉
The release is available on:

• GitHub Release
• Chocolatey Package
• .Net Global Tool

Your GitReleaseManager bot 📦🚀