Skip to content

2 remote(s) have been detected error. #1390

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
quasarea opened this issue Mar 20, 2018 · 5 comments
Closed

2 remote(s) have been detected error. #1390

quasarea opened this issue Mar 20, 2018 · 5 comments

Comments

@quasarea
Copy link

quasarea commented Mar 20, 2018

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
Copy link
Author

@asbjornu
Copy link
Member

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
Copy link
Author

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
Copy link
Member

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
Copy link
Author

It is solved now, thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants