VSTS Build vNext task not finding current version

[jdshkolnik]

Hi,

First, I'd like to thank you for making this. It's a very significant utility.

I'm experimenting without having changed any of the default settings. My master branch is in sync between local and remote origin.

When I run GitVersion /output json /showvariable FullSemver in my local repo I get 1.7.0+20. It sees a merge from release/1.6.2 and then picks up '+semver: minor' in one of the commit messages.

When I run a build in VSTS against that same master repo, it labels as 0.2.0+25. It falls back to 0.1.0 then picks up '+semver: minor' in one of the commit messages.

Any thoughts as to why they're behaving differently?

Here's some output from the build definition:

Current Directory: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\1.104.1\tasks\GitVersion\3.6.2
Sources Directory: C:\a\1\s
Invoking GitVersion with C:\a\1\s /output buildserver /nofetch
C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\1.104.1\tasks\GitVersion\3.6.2\GitVersion.exe C:\a\1\s /output buildserver /nofetch
Working directory: C:\a\1\s
IsDynamicGitRepository: False
Returning Project Root from DotGitDirectory: C:\a\1\s.git - C:\a\1\s
Running on Windows.
Applicable build agent found: 'VsoAgent'.
Branch from build environment: refs/heads/master
IsDynamicGitRepository: False
Returning Project Root from DotGitDirectory: C:\a\1\s.git - C:\a\1\s
Project root is: C:\a\1\s
DotGit directory is: C:\a\1\s.git
IsDynamicGitRepository: False
Returning Project Root from DotGitDirectory: C:\a\1\s.git - C:\a\1\s
Begin: Loading version variables from disk cache
Cache file C:\a\1\s.git\gitversion_cache\27B03834EC80B83A6947A985F59DFC7221371A01.yml not found.
End: Loading version variables from disk cache (Took: 1.00ms)
IsDynamicGitRepository: False
Returning Project Root from DotGitDirectory: C:\a\1\s.git - C:\a\1\s
Using latest commit on specified branch
Running against branch: master (6597f9d637c909f29c3e73fc13f5018e319702ac)
Begin: Calculating base versions
Fallback base version: 0.1.0 with commit count source 68b94cdf37d37544f606a9bf51461598cf776000
Base version used: Fallback base version: 0.1.0 with commit count source 68b94cdf37d37544f606a9bf51461598cf776000
End: Calculating base versions (Took: 176.01ms)
25 commits found between 68b94cdf37d37544f606a9bf51461598cf776000 and 6597f9d637c909f29c3e73fc13f5018e319702ac
Begin: Creating dictionary
End: Creating dictionary (Took: 3.01ms)
Begin: Storing version variables to cache file C:\a\1\s.git\gitversion_cache\27B03834EC80B83A6947A985F59DFC7221371A01.yml
End: Storing version variables to cache file C:\a\1\s.git\gitversion_cache\27B03834EC80B83A6947A985F59DFC7221371A01.yml (Took: 42.00ms)
Applicable build agent found: 'VsoAgent'.
2016-08-22T02:32:33.8800370Z Executing GenerateSetVersionMessage for 'VsoAgent'.
2016-08-22T02:32:34.3534582Z Executing GenerateBuildLogOutput for 'VsoAgent'.

[JakeGinnivan]

Can you copy the fetch sources part of the build log. Looks like tags are not being fetched.

[jdshkolnik]

Entering GitSourceProvider.PrepareRepositoryAsync
Repository type=TfsGit
localPath=C:\a\1\s
clean=True
sourceBranch=refs/heads/master
sourceVersion=6597f9d637c909f29c3e73fc13f5018e319702ac
Syncing repository: Blah-Blah-Blah (Git)
repository url=https://?.visualstudio.com/?/_git/Blah-Blah-Blah
checkoutSubmodules=False
Starting clone
Checking out 6597f9d637c909f29c3e73fc13f5018e319702ac to C:\a\1\s
Checked out branch refs/heads/master for repository Blah-Blah-Blah at commit 6597f9d637c909f29c3e73fc13f5018e319702ac
Leaving GitSourceProvider.PrepareRepositoryAsync

[jdshkolnik]

I was able to get around it by not using squash merge. Jesse Houwing from Xpirit figured it out so I'll let him fill in the details.

[roryprimrose]

I use squash merges as well but I'm finding tags are not being picked up even using git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" fetch --prune --progress origin to get around to get around the master/develop not being pulled when building pull requests (as per #993).

@JakeGinnivan Should I do the above CLI as well as git fetch -all? I'm clutching as straws here :)

[jdshkolnik]

Excerpt from Jesse's email:

I followed the standard merge process on the Pull Request workflow (with a fast-forward possible merge), but got a merge-commit as expected:

Cd95da0a was the original state
I added a file in 6ce8def7
I create and accepted a pull request
Which added the merge commit: 6a0bcacf

Now let’s check the squash option for a second PR:

That will combine all commits together (even the merge commit) and performs a commit:

So you lose the git history. The Web UI doesn’t expose the -no-ff option, it seems to always apply it, unless squash is selected.

[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.