GitVersion checks out tagged commit, not the latest

[GeertvanHorrik]

Currently testing an issue where the combination of dynamic repositories and a beta release branch are not being able to find the specified commit sha (and thus using the base, which is the initially tagged commit) as current commit. This results in the versions always being calculated as beta-0.

[GeertvanHorrik]

The issue seems to be coming from GitPreparer::CreateDynamicRepository where GitRepositoryHelper.NormalizeGitDirectory checks out the target branch, but not the target commit.

[GeertvanHorrik]

@JakeGinnivan question: why doesn't beta automatically get increased for each commit (where this does happen for the develop branch)? I am trying to migrate from 3.2.0 => 4.0.0-beta, and want to understand why this behavior was changed.

[GeertvanHorrik]

Weird, I have a release/2.3.0 branch and a develop branch. Looks like the dynamic repository stuff is checking out the develop branch as release/2.3.0 locally. So it doesn't actually fetch the right branch. Looking into this.

[GeertvanHorrik]

Seems to be an issue in GitTools.Core, will provide a fix today. That only leaves out the question why NextVersionCalculator::UpdatePreReleaseTag defaults to 1 instead of BuildMetaData.CommitsSinceTag.

[GeertvanHorrik]

Created PR for GitTools.Core. For the counter issue, I am suggesting to add this to NextVersionCalculator::UpdatePreReleaseTag:

            if (number == null)
            {
                number = semanticVersion.BuildMetaData.CommitsSinceTag + 1;

                if (number == null)
                {
                    number = 1;
                }
            }

In this case, when we are not using tags (which we should increase), it will use the commits since the tags (keeping the old method alive where each commit on a release branch ensures a unique prerelease version).

[GeertvanHorrik]

It does break a lot of unit tests. I can see where the idea is coming from to have to explicitly tag a commit (since some people want to include multiple commits into a beta). However, this breaks the auto-counting strategy I am using on my projects. Now I need to explicitly specific a new beta version number (as a tag) before releasing one. If I forget (this manual process), it will fail. Is introducing this as a configuration an option?

[JakeGinnivan]

Can you explain your auto-counting strategy. There is likely already a configuration option or mode which works.

Develop is configured to use ContinuousDeployment by default whereas other branches do not.

[GeertvanHorrik]

This is my config:

mode: ContinuousDeployment
assembly-versioning-scheme: MajorMinorPatch 
next-version: 2.3.0

I was on an older version (the last one that had dynamic repositories working) and unfortunately I was too busy to keep up with all the great changes you made to GV. Since I need the alpha instead of unstable tags now, I am "forced" to upgrade (which is actually good since I can finally fix the dynamic repositories).

Anway, back to your original question. Before this, we had a release branch (e.g. release/2.3.0) and committed changes to fix issues found in our beta versions. Every change would be a new version (e.g. 12 commits would result into 2.3.0-beta12). However, it looks like it currently does not count the commits since tag, but it only increases the tag (if it finds one) or starts at 1.

The change I proposed (always use commitssince instead of 1 as default) breaks unit tests because it no longer results in versions 1+5 (where 1 is the tag counter, 5 is the commit counter). Basically I am only interested in beta1 since everything else requires me to either update the build scripts for all products (and there are about 100) or tag every beta release manually. For now only have a few manual steps in mind:

1. Create release branch (start betas)
2. Finalize release branch (create stable version)

The rest should (in our case) be fully automatic.

[bennettfactor]

When I try to manually use 1.3.1 GitTools.Core (with your fix in it) in the latest GitVersion (v4.0.0-beta.13) I am getting this error: "GitTools.Core has a bug, your HEAD has moved after repo normalisation."

When running against "develop" and using dynamic repo:

1. The dynamic repo that gets checked out initially checks out master
2. var expectedSha = repo.Head.Tip.Sha; in NormalizeGitDirectory gets the HEAD of master
3. EnsureLocalBranchExistsForCurrentBranch executes a checkout of develop (the branch I passed in)
4. The SHA of the develop branch does not match the sha of the master branch from (1).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.