GitVersion should only consider tags matching current branch config (was: GitVersion fails to return correct version when tag exists on commit)

[DocZoid]

Describe the bug
Tags have a too strong weight on the version evaluation which I feel is a bug. I am quite new to versioning and GitVersion, so I might be on the wrong track without knowing. I have read in some other issue that fast-forward merges for master are generally discouraged (forbidden?), and this is a part of my issue (#2). The proposed fix would as a side effect allow using fast-forward merges in my opinion.

There are two scenarios where the tag should not be used to evaluate the version:

1. When I build a snapshot from the develop branch, tag the branch with the created version (e.g. 0.1.2-snapshot.2), and then branch this commit to a new release (release/0.1.2)
2. When I build a release candidate from a release branch, tag the release branch with the new created version (e.g. 0.1.2-rc.1), and then make a fast-forward merge to master, essentially having master point to that tagged commit

Expected Behavior

1. The resulting version should be 0.1.2-rc.1 (with the release configuration "tag: rc")
2. The resulting version should be 0.1.2

Actual Behavior

1. The resulting version is 0.1.2-snapshot.2 based on the tag
2. The resulting version is 0.1.2-rc.1 based on the tag

Possible Fix

Multiple branches point to the same commit. This is confusing GitVersion, which takes tags from that commit, but it does not respect the branch configuration of the current branch when analyzing the tags, e.g. when I am working on a release branch, it should only look for previous version tags which are formatted like its own tag configuration in the release branch ("with "rc" in it, so tags 0.1.2-rc.1 should be considered, but not 0.1.2-snapshot.2, because of the configuration "tag: rc")

Steps to Reproduce

1. assume or create config: "develop -> tag: snapshot", "release -> tag: rc"
2. tag a commit in "develop" with a version tag, e.g. 0.1.2-snapshot.2
3. branch that commit to release/0.1.2
4. using release/0.1.2 as current branch, run GitVersion. Calculated version should be 0.1.2-rc.1 instead of 0.1.2-snapshot.2

Context

We have commit hooks checking every commit message. Therefor, it seems like an easy option to use fast-forward merges for master to avoid commits, but GitVersion is missing the mentioned configuration option to be able to handle fast-forward merges.
Also, I do not know how GitVersion is intended to be used when creating a release branch without adding an empty commit on that branch before building it, if the commit already has a tag. Deleting all tags locally would be a workaround, but it has a smell of nastiness.

Your Environment

• Version Used: 5.3.3+Branch.master.Sha.08a43ede0b292c8ce2178b3d305587f151a2bdf4
• Operating System and version (Windows 10, Ubuntu 18.04): Windows 10
• Link to your project: -
• Link to your CI build (if appropriate): -

[asbjornu]

The workflow you are describing is not supported by GitVersion. The closest match you have may be Mainline mode, but tags are going to have the highest weight when figuring out a version number no matter what you do. This is by design and is not going to change.

[DocZoid]

Can you elaborate more on why the workflow is not supported? I use GitFlow, with develop creating snapshots (instead of alpha). Mainline mode does not suite our development needs.

I know that it is a design decision to build versions preferably by using the commit's tag, and I am not suggesting to remove it, but rather to improve it. Of course this can also be a configurable option for each branch. The option could work like that: (in the branch configuration) consider-tags-of-other-branches: <true/false>, or more general, but probably over-the-top: filter-tag-regex: .*. Setting the first option to false yields the current behaviour. True would create a regex <SemVer-regex>-<tag-param of branch>.* to filter the found tags before actually analyzing them (or only <SemVer-regex> if tag is set to '').

If that improvement is not an option (apart from possible minor bugs in my suggested implementation), please explain why, and what I could change to build a release (candidate) from an already tagged commit.

[asbjornu]

Perhaps I'm not properly understanding your use-case. Please submit a PR with a RepositoryFixture that implements the behaviour you'd like to see.

[DocZoid]

I'd like to, but the way of working for such a change and the GitVersion internals are all new to me. But I'll try to get through it.

I just did a code analysis to find a place where I would assume the change to take place.

In TaggedCommitVersionStrategy.cs I see a comment /// Version is extracted from all tags on the branch which are valid, and not newer than the current commit.. I want to point out that the comment (and the following code examples) all state that the tags have to refer to the current branch, not the current commit. When using FF merges or when branching (and not committing after branching), commits (and their tags) may belong to multiple branches. This cannot be distinghuished in GIT, but it can in GitVersion, based on the configuration.

My intention is to have GitVersion focus more on the current branch and disregard tags on the same commit, but belonging to another branch (again, using the configuration to tell to which branch a tag belongs).

The essential code seems to be in GetTaggedVersions:

         var tagsOnBranch = currentBranch
               .Commits
               .SelectMany(commit => { return allTags.Where(t => IsValidTag(t.Item1, commit)); })
               .Select(t =>
               {
                   if (t.Item1.PeeledTarget() is Commit)
                       return new VersionTaggedCommit(t.Item1.PeeledTarget() as Commit, t.Item2, t.Item1.FriendlyName);

                   return null;
               })
               .Where(a => a != null)
               .Take(5)
               .ToList();

where t.Item1.FriendlyName refers to the tag name. I would want to filter that to have a prefix that matches the configured tag in the GitVersion branch configuration (e.g. "release: tag: rc" means if the current branch is release, all tags returned here should have the prefix "rc", meaning they actually belong to the current branch. Do not consider tags with other prefixes, like "snapshot.32", since we are on a release branch and do not want to build a snapshot, but a release candidate).

Is there a function somewhere that can tell me if a Git-tag matches a specific configured branch tag? How would I get the configured branch tag? Also, two special cases have to be considered: if the configured branch tag is empty (e.g. master branch), the match must yield true if the Git-tag has no prefix, and if the configured branch tag is "useBranchName", this has to be resolved.

[asbjornu]

Adding a test shouldn't require deep knowledge about the GitVersion codebase. They are pretty straight forward:

GitVersion/src/GitVersionCore.Tests/IntegrationTests/VersionInTagScenarios.cs

Lines 33 to 52 in e8102ab

	[Test]
	public void TagPreReleaseWeightIsConfigured_HeadIsATaggedCommit_WeightedPreReleaseNumberShouldBeTheSameAsTheTagPreReleaseWeight()
	{
	// Arrange
	var config = new ConfigurationBuilder()
	.Add(new Config
	{
	AssemblyFileVersioningFormat = "{Major}.{Minor}.{Patch}.{WeightedPreReleaseNumber}",
	TagPreReleaseWeight = 65535
	})
	.Build();
	// Act
	using var fixture = new BaseGitFlowRepositoryFixture("1.0.0");
	fixture.MakeATaggedCommit("1.1.0");
	var version = fixture.GetVersion(config);
	// Assert
	version.AssemblySemFileVer.ShouldBe("1.1.0.65535");
	}

Start with writing a test that provokes the behaviour you're experiencing, then you can start deep-diving into the code and change things to see whether it fixes your problem or not. Without seeing a reproduction in a test, it's very hard for me to help you figure out where or how to fix your problem, so please start there. You can submit a draft pull request to allow feedback and discussion before the problem is solved and the PR is good for a final review and merge.

My intention is to have GitVersion focus more on the current branch and disregard tags on the same commit, but belonging to another branch (again, using the configuration to tell to which branch a tag belongs).

This sounds impossible. Git doesn't have a link between branch and tag references. To Git, they are basically the same: a reference to a commit. So as long as you have a tag reference to the same commit that is checked out, which branch was checked out when the commit was made, is irrelevant. You would need to add another commit to the current branch to deviate from the "tagged branch" so to say.

[DocZoid]

I'll try to get quite close to it for one example at least, based on some other tests. Apologies for likely mistakes.

        [Test]
        public void BetaBranchCreatedButStillOnTaggedAlphaCommitShouldCreateBetaVersion()
        {
            // Arrange
            var config = new Config
            {
                Branches =
                {
                    { "release", new BranchConfig { Tag = "beta" } },
                    { "develop", new BranchConfig { Tag = "alpha" } }
                }
            };

            // Act
            using var fixture = new BaseGitFlowRepositoryFixture("1.0.0");
            //not sure if needed
            //fixture.Checkout("master");
            //fixture.MergeNoFF("develop");
            fixture.Checkout("develop");
            fixture.MakeACommit("Feature commit 1");
            fixture.ApplyTag("1.1.0-alpha.1"); // assuming this has been build as 1.1.0-alpha.1
            fixture.BranchTo("release/1.1.0"); // about to be released
            //fixture.MakeACommit("Release commit 1"); // no additional empty commit in this scenario!
            fixture.Checkout("release/1.1.0"); // still on the same commit, but another branch, choosing to build same code as beta
            fixture.AssertFullSemver("1.1.0-beta.1", config); //will be 1.1.0-alpha.1, should be 1.1.0-beta.1. Tag is an "alpha" tag, only "beta" tags should count when on release branch. If no beta tag found, build new beta version on release branch.
            fixture.Checkout("develop"); // back to develop
            fixture.AssertFullSemver("1.1.0-alpha.1", config); //will be 1.1.0-alpha.1 based on tag (as before)

            var version = fixture.GetVersion(config);

            // Assert
            // done in-line
        }

[asbjornu]

Sorry, but writing code in a comment is not the same as submitting a draft pull request, @DocZoid.

[DocZoid]

Sorry, but you are not being helpful either, @asbjornu .
I'm just getting as far as I can with the time I have. It might take some time until I have a pull request out, and I was hoping for some constructive feedback.

[asbjornu]

Sorry, but the constructive feedback is very hard to give on an island of code like that. If I had a proper draft pull request to look at, I would for instance know whether the code even compiled and the result of the test would be available to me. As presented, I would have to open my editor, paste in your code, compile it, execute tests, etc. That requires me to actually block out time to even know what I'm looking at here. If you are unable to allot the required time and energy to submit a draft pull request, I'm not going to be able to allot the required time and energy to give you feedback. Sorry.

[DocZoid]

I never said that I won't make a pull request, it's just small steps with a fail-fast mindset (if you tell me "that won't work because you have not considered <mutant unicorns>" I might as well give it up altogether).

Well, I have checked out the code and added a (hopefully improved) test. I have no access to push the commit - is it something I have to look up in GitHub or do you need to give me repo rights? I didn't use GitHub for contributing yet and the permissions doc page I found didn't help.

Edit: I believe I need collaborator rights

[arturcic]

@DocZoid

Well, I have checked out the code and added a (hopefully improved) test. I have no access to push the commit - is it something I have to look up in GitHub or do you need to give me repo rights? I didn't use GitHub for contributing yet and the permissions doc page I found didn't help.

We don't give permissions to directly commit the changes to the repository. But all those that want to contribute usually fork the repository, make the adjustments in their fork then they create a pull request against the original repository.