2 remote(s) have been detected error.

[quasarea]

Relates to #1311, the merge from #1313 does not solve this issue.

Replicated both in
4.0.0-beta.12+1315.Branch.master.Sha.9c70946f68973b3b31b2861913c247fbe6c3f0ec
4.0.0-beta.13+1425.Branch.master.Sha.0f7e7b3d845cd5ebd39bdb7f5459d34fb84e8b3d

I'm using jenkins multibranch pipeline, bitbucket one to be exact.
It seems that git plugin (https://plugins.jenkins.io/git) while working on pull request not a branch, uses additional remote to notify back bitbucket PR about build outcome.

Because of so, removing the upstream remote seems to not be the solution. Leaving it in brings "2 remote(s) have been detected error.".

I came up with using the gitversion on remote branch directly, instead of using local branch, so instead of:

.\packages\GitVersion.CommandLine\tools\GitVersion.exe /showvariable FullSemVer

I'm doing

.\packages\GitVersion.CommandLine\tools\GitVersion.exe /showvariable FullSemVer /url https://stash.company.com/scm/team/component.git /b ${gitbranch} /u ${gituser} /p ${gitpass}

the problem is that I'm getting different outcome. the first command in debug shows:

INFO [03/20/18 12:00:30:85] Running against branch: feature/gitversion (0929493ee803f34c78cbe5234943562ed6ae8c20)
INFO [03/20/18 11:52:31:94] 151 commits found between 96e9db0676ecf17faf1826ce15209719b8339b93 and 0929493ee803f34c78cbe5234943562ed6ae8c20

the other

INFO [03/20/18 11:59:35:39] Running against branch: feature/gitversion (96c52366afddb0274648b3458326002ab2431bf0)
INFO [03/20/18 11:55:36:72] 138 commits found between 96e9db0676ecf17faf1826ce15209719b8339b93 and 96c52366afddb0274648b3458326002ab2431bf0

The outcome of second points to last change on master. I played a bit with this, and whatever branch name I will use (even not existing one) it always pretends that everything is fine and returns 138 commits distance. Using debug verbosity does not yield any warnings.

[quasarea]

log-local.txt
log-remote.txt

[asbjornu]

I think the right solution to avoid normalization is #1243 or #1244, but they are still quite some way from being ready. If you can help out getting those done, it would be highly appreciated.

[quasarea]

Thanks, will see if I can help you out with those, but above issue seems like genuine bug rather than lack of features. Querying the same thing from develop branch yields not correct result if you do this on remote directly.

Current workaround is to remove the upstream remote before giversion and add it back after, unfortunately I cannot replicate perfectly the remote declaration that jenkins is doing but got it close enough to work.

[asbjornu]

The reason I believe normalization is causing problems are these lines from the log:

INFO [03/20/18 13:16:09:56] Begin: Normalizing git directory for branch 'feature/gitversion'
INFO [03/20/18 13:16:09:86] Updating local branch refs/heads/feature/gitversion to match ref feature/gitversion

GitVersion shouldn't really be manipulating the repository, it should just act on it as is. Any missing information needs to be fetched in place before GitVersion starts operating, we can't adjust for every build server's way of Git remote fetch optimization.

So, you should not in any way have to remove the upstream remote. This is indeed a bug and not a missing feature. The two pull requests I mentioned previously are mostly about fixing bugs like these, but will have the added benefit of improving the speed, reliability and testability of GitVersion.

[quasarea]

It is solved now, thanks