GitVersion in a Jenkins Multibranch Pipeline job

Question

We use Jenkins CI and have recently been experimenting with GitVersion for automatically generating SemVer version numbers. However, when combining GitVersion with Multibranch Pipeline jobs (which automatically build branches and PRs for a given Git repository), we've run into GitVersion's limitation of only one remote (as enforced by its NormalizeGitDirectory function). The specific error we encounter is:

System.ComponentModel.WarningException: 2 remote(s) have been detected. When being run on a build server, the Git repository is expected to bear one (and no more than one) remote.

The only solution we've found (as blogged here) is to manually remove the "origin1" remote after the SCM checkout, prior to any build steps that would invoke GitVersion, like so:

bat 'git remote remove origin1'

This works but feels very much like a hack, and would likely not work with any fork-sourced PRs.

Is there a better solution out there?

Spirt

I am not familiar with the Multibranch Pipeline job, where is your git repo hosted? Normally providers like GitHub/VSTS etc create refs under pulls/<prnumber>/merge which is the result of the PR branch pre-merged with the target branch. This means you can just specify the pulls/<prnumber>/merge refspec to cause it to fetch pull requests and trigger builds. Could you explain the scenario where you need two branches in a single build so I can recommend a better solution? – Bascom

@JakeGinnivan, we're hosted on GitHub Enterprise. The Multibranch Pipeline job's purpose is to build PRs and branches automatically from a Git repository location. This is done by adding a refspec "+refs/pull//head:refs/remotes/origin/pr/" along with the default "+refs/heads/:refs/remotes/origin/". It seems this is currently handled by the Git Plugin as two separate remotes instead of a single remote with multiple refspecs. – Spirt

Answer 1

It seems that with pull request two remotes are required to track the build result for both (at least I was not getting back results on PR when upstream remote was removed)

Using current 4.0.13 beta (and .12 beta) I tried to solve it by pulling directly, but there is a bug that affects calculation of current version when used directly (https://github.com/GitTools/GitVersion/issues/1390)

My current workaround is to remove upstream remote before:

def remotes = bat(script: "@call git remote show", returnStdout: true).trim().readLines()
def hasUpstream = remotes.any { it == "upstream" }
def upstreamURL
if (hasUpstream) {
    echo "Remote 'upstream' detected -- ${env.BRANCH_NAME} is pull request, removing remote for further processing"
    upstreamURL = bat(script: "@call git remote get-url upstream", returnStdout: true).trim()
    bat "git remote remove upstream"
}

then execute:

def command = "@call ${BuildInfo.GitVersion.Run} /updateassemblyinfo /ensureassemblyinfo /nofetch /verbosity debug"
def output = bat(script: command, returnStdout: true).trim()

and add it back after:

if (hasUpstream) {
    echo "Restoring 'upstream' remote using url: ${upstreamURL}"
    bat "git remote add -t master --tags upstream ${upstreamURL}"
}

Entomophilous