Gitversion: Error / GitVersion with Jenkins multi-branch pipeline project

[vader1986]

This might be related to https://github.com/GitTools/GitVersion/issues/912 .

With the default configuration of a multi-branch pipeline project in Jenkins, it's complaining:

An unexpected error occurred: System.InvalidOperationException: Could not find a 'develop' or 'master' branch, neither locally nor remotely.

If I do git fetch --all after checkout, I'm getting:
LibGit2Sharp.LibGit2SharpException: ref '...' doesn't match the destination

Interestingly enough, it works, when I

1. change the default Jenkins configuration (which we cannot do in production!) to fetch refspec for latest master
2. and to checkout the current branch locally
3. and I run git checkout master followed by git checkout ${GIT_BRANCH} in the Jenkins pipeline file

[vader1986]

For people with similar problems, I've got a workaround. Open the Jenkins multi-branch pipeline project:

• Scroll down to Projects - Bitbucket Team/Project
• Add a new item to Behaviors: Check out to matching local branch
• Add a new item to Behaviors: Specify ref specs
• Change the default value of Ref Spec to "+master:@{remote}/master"
• Apply and save the configuration

[JonCubed]

from memory, Jenkins does a shallow clone so only knows about the branch it is cloning. Have you tried fetch tags option in Advanced clone behaviours. If I remember correctly it shows checked event though it really should be unchecked and you have to uncheck, save -> check and save for it to work properly

[vader1986]

Oh interesting! I'll give it a try!

Edit: I unchecked fetch tags in advanced clone behavior. Unfortunately, this did not fix the problem.

Also, the step Change the default value of Ref Spec to "+master:@{remote}/master" causes problems when creating branches from any branch other than master-branch. So that is certainly not a good solution.

[JonCubed]

@vader1986 from your edit it seems like you didn't recheck fetch tags and save after you saved it as unchecked. You really do want it to fetch tags but this UI bug makes it seem like its on when it is not, so doing this sync up the UI.

[vader1986]

Hi, thanks for the reply! I did save after unchecking, but I just rebuild the existing branch. That means it was actually not cloning the repo again, therefore, "cloning behavior" wasn't applied. I guess it would be nice to fetch all after each update of the branch, rather than just for cloning.

I'll try to play around a bit more with the Jenkins settings.

[josephearl]

Believe I'm getting a similar error when trying to build a GitHub pull request with Jenkins pipeline.

Log file:

2018-02-16 11:10:48     INFO [02/16/18 11:10:48:38] Working directory: ..
2018-02-16 11:10:48     INFO [02/16/18 11:10:48:39] IsDynamicGitRepository: False
2018-02-16 11:10:48     INFO [02/16/18 11:10:48:43] Returning Project Root from DotGitDirectory: /home/jenkins/workspace/ervice.IdentityClient_PR-18-Z2QNFMOZ2OQQCN5P73KIYJ4LWQ4A2SRSKBDXZZ4BEZQ6VCDR3VQA/.git - /home/jenkins/workspace/ervice.IdentityClient_PR-18-Z2QNFMOZ2OQQCN5P73KIYJ4LWQ4A2SRSKBDXZZ4BEZQ6VCDR3VQA
2018-02-16 11:10:48     INFO [02/16/18 11:10:48:43] Running on Mono.
2018-02-16 11:10:48     INFO [02/16/18 11:10:48:44] Applicable build agent found: 'Jenkins'.
2018-02-16 11:10:48     INFO [02/16/18 11:10:48:44] Branch from build environment: 
2018-02-16 11:10:48     ERROR [02/16/18 11:10:48:96] An unexpected error occurred:
LibGit2Sharp.LibGit2SharpException: ref 'refs/remotes/origin/master' doesn't match the destination
  at LibGit2Sharp.Core.Ensure.HandleError (System.Int32 result) [0x00057] in <1a5aafd5a5444cd6a1420741ccbb6f8a>:0 
  at LibGit2Sharp.Core.Ensure.ZeroResult (System.Int32 result) [0x00004] in <1a5aafd5a5444cd6a1420741ccbb6f8a>:0 
  at LibGit2Sharp.Core.Proxy.git_refspec_rtransform (System.IntPtr refSpecPtr, System.String name) [0x0000f] in <1a5aafd5a5444cd6a1420741ccbb6f8a>:0 
  at LibGit2Sharp.Remote.FetchSpecTransformToSource (System.String reference) [0x00026] in <1a5aafd5a5444cd6a1420741ccbb6f8a>:0 
  at LibGit2Sharp.BranchUpdater.GetUpstreamInformation (System.String canonicalName, System.String& remoteName, System.String& mergeBranchName) [0x0004e] in <1a5aafd5a5444cd6a1420741ccbb6f8a>:0 
  at LibGit2Sharp.BranchUpdater.SetUpstream (System.String upstreamBranchName) [0x00018] in <1a5aafd5a5444cd6a1420741ccbb6f8a>:0 
  at LibGit2Sharp.BranchUpdater.set_TrackedBranch (System.String value) [0x0000f] in <1a5aafd5a5444cd6a1420741ccbb6f8a>:0 
  at GitTools.Git.GitRepositoryHelper+<>c__DisplayClass8_1.<CreateOrUpdateLocalBranchesFromRemoteTrackingOnes>b__2 (LibGit2Sharp.BranchUpdater b) [0x00000] in <57cedcc684654481ace045b6d7bcc156>:0 
  at LibGit2Sharp.BranchCollection.Update (LibGit2Sharp.Branch branch, System.Action`1[LibGit2Sharp.BranchUpdater][] actions) [0x00017] in <1a5aafd5a5444cd6a1420741ccbb6f8a>:0 
  at GitTools.Git.GitRepositoryHelper.CreateOrUpdateLocalBranchesFromRemoteTrackingOnes (LibGit2Sharp.Repository repo, System.String remoteName) [0x001ce] in <57cedcc684654481ace045b6d7bcc156>:0 
  at GitTools.Git.GitRepositoryHelper.NormalizeGitDirectory (System.String gitDirectory, GitTools.Git.AuthenticationInfo authentication, System.Boolean noFetch, System.String currentBranch) [0x0006c] in <57cedcc684654481ace045b6d7bcc156>:0 
  at GitVersion.GitPreparer.Initialise (System.Boolean normaliseGitDirectory, System.String currentBranch) [0x00016] in <57cedcc684654481ace045b6d7bcc156>:0 
  at GitVersion.ExecuteCore.ExecuteGitVersion (System.String targetUrl, System.String dynamicRepositoryLocation, GitVersion.Authentication authentication, System.String targetBranch, System.Boolean noFetch, System.String workingDirectory, System.String commitId, GitVersion.Config overrideConfig) [0x00041] in <57cedcc684654481ace045b6d7bcc156>:0 
  at GitVersion.SpecifiedArgumentRunner.Run (GitVersion.Arguments arguments, GitVersion.Helpers.IFileSystem fileSystem) [0x00074] in <57cedcc684654481ace045b6d7bcc156>:0 
  at GitVersion.Program.VerifyArgumentsAndRun () [0x00124] in <57cedcc684654481ace045b6d7bcc156>:0 
2018-02-16 11:10:48     INFO [02/16/18 11:10:48:96] 
2018-02-16 11:10:48     INFO [02/16/18 11:10:48:96] Attempting to show the current git graph (please include in issue): 
2018-02-16 11:10:48     INFO [02/16/18 11:10:48:96] Showing max of 100 commits
2018-02-16 11:10:49     INFO [02/16/18 11:10:49:02] * f8fe5ec 10 minutes ago  (HEAD, origin/PR-18, PR-18)
* 2109672 13 minutes ago 
* 69569d0 20 minutes ago  (origin/master, master)
* f9c1d3b 22 minutes ago 
* 754c780 24 minutes ago 
* 93b9f62 28 minutes ago 
* 1812ce4 13 hours ago 
* 4959c2a 14 hours ago 
* 2347ad7 16 hours ago 
* 43a3e5c 19 hours ago 
* 33cc300 19 hours ago 
* de25a72 19 hours ago 
* f56e7d4 2 days ago 
* a269416 2 days ago 
* 2af7d5f 2 days ago 
* 08b4272 2 days ago 
* bd956a2 3 days ago  (tag: 0.1.5)
* 7bbe08a 4 days ago  (tag: 0.1.4)
* 283dd5f 4 days ago  (tag: 0.1.3)
* ee81ff5 9 days ago  (tag: 0.1.2)
* 747d6f3 9 days ago 
* eddb35d 9 days ago 
* abbdce2 9 days ago 
* 266080e 9 days ago 
* ac494d4 9 days ago 
* 1abfc75 9 days ago 
* c1ffd29 9 days ago 
* 4415350 10 days ago 
* b2dcc33 11 days ago 
* e5a9a16 11 days ago  (tag: 0.1.1)
* 9845fe7 11 days ago 
* 126d801 11 days ago 
* 6f08fac 2 weeks ago 
* 924d113 2 weeks ago 
* f8228ef 2 weeks ago 
*   f3e365f 2 weeks ago 
|\  
| * c793b4f 2 weeks ago 
| * a450f93 2 weeks ago 
| * 566837e 2 weeks ago 
* | 72d7733 2 weeks ago 
|/  
* b804eb8 2 weeks ago 
* c95868e 2 weeks ago 
* 107aa54 2 weeks ago 
* b62835a 2 weeks ago 
* 2aa6946 2 weeks ago 
* b4023ab 2 weeks ago 
* d6349aa 3 weeks ago 
* a8a0e49 3 weeks ago 
* 7133d3c 3 weeks ago 
* 173966e 3 weeks ago 
* d0d6395 3 weeks ago 
* 9b401c9 3 weeks ago 
* a7b7064 3 weeks ago 
* af25f10 3 weeks ago 
* 46842bf 3 weeks ago 
* 307cb4e 3 weeks ago 
* f0c3f56 3 weeks ago 
* 1f8de20 3 weeks ago 
* 70e014b 3 weeks ago 
* 4017a9b 3 weeks ago 
* a2f57bb 3 weeks ago 
* 948daab 3 weeks ago 
* 664bb9a 3 weeks ago 
*   c19a358 3 weeks ago 
|\  
| * 35afbd1 3 weeks ago 
| * 7ba8920 3 weeks ago 
| * 889a1d1 3 weeks ago 
| * 704dfd3 3 weeks ago 
* | 0cda5a4 3 weeks ago 
|/  
* ae6f19a 3 weeks ago 
* db9a124 3 weeks ago 
* ffd8813 3 weeks ago 
* 64fea9a 3 weeks ago 
* ed06d0b 3 weeks ago 
*   cff2621 3 weeks ago 
|\  
| * 8554fe1 3 weeks ago 
* |   6cde527 3 weeks ago 
|\ \  
| |/  
|/|   
| * 435bc7b 3 weeks ago 
* | 0d9bc69 3 weeks ago 
|/  
* 97772fe 5 weeks ago 
* 9fe2c2a 5 weeks ago 
* 7533a3b 5 weeks ago 
* 95edd1c 5 weeks ago 
* c38b291 5 weeks ago 
* 804e4ef 5 weeks ago 
* a0370cf 5 weeks ago 
* 340cbce 5 weeks ago 
* 2d22cc4 5 weeks ago 
* be5239c 5 weeks ago 
* 2cece63 5 weeks ago 
* 76784ae 5 weeks ago 
* dc41878 5 weeks ago 
* fff5d29 5 weeks ago 
* 35abd8b 5 weeks ago 
* 0627fb2 5 weeks ago 
* 97d8fd6 5 weeks ago 
* 9afdc88 5 weeks ago 
* 4a2cc5e 5 weeks ago 
* ab16dd0 5 weeks ago 
* 3078e35 5 weeks ago 

I have Jenkins set to checkout tags and not do a shallow clone with the following in my Jenkinsfile:

        checkout([
          $class: 'GitSCM',
          branches: scm.branches,
          doGenerateSubmoduleConfigurations: scm.doGenerateSubmoduleConfigurations,
          extensions: scm.extensions + [[$class: 'CloneOption', noTags: false, reference: '', shallow: false]],
          userRemoteConfigs: scm.userRemoteConfigs
        ])

[asbjornu]

Is it possible to perform a git fetch --unshallow just before GitVersion is executed? Does that help?

[josephearl]

In my case I tried that and got:

+ git fetch --unshallow
fatal: --unshallow on a complete repository does not make sense

[asbjornu]

I see. How about git fetch --all?

[wmclifford]

I ran into this the other day, and I got it to work using
+refs/heads/*:refs/remotes/@{remote}/* for the ref spec. IIRC, +master:@{remote}/master will try and add master from the local repository in your workspace. Try the ref spec I used, and if you want to limit it to only add master on the remote, use +refs/heads/master:refs/remotes/@{remote}/master. That had worked as well, but I had to open my capture up for other reasons.

[theschnarr]

Just to add to this thread, I'm running into this issue with a multi-branch pipeline script in Jenkins too.
The +refs/heads/*:refs/remotes/@{remote}/* workaround above works, except when it's the first build of a new workspace.
Typically, I see this in a pull request, or on the initial push of a new branch. The first build fails, with the error described above. When I re run the build, it works.

[onuralp]

Here is my solution;

#!groovy

pipeline {

    //..

    stages {
        stage('GitVersion') {
            steps {
                // A workaround for the following issue
                // See: https://github.com/GitTools/GitVersion/issues/1335
                sshagent(['your-github-ssh-cred-id']) {
                    bat 'git fetch origin master:master'
                    bat 'git fetch origin develop:develop'
                }
                bat 'GitVersion'
            }
        }
    }

    //..
}

PS: If ssh-agent doesn't work for you, run the following command to add git bash to your path
setx /M PATH $( $env:Path.TrimEnd(';') + ';C:\Program Files\Git\usr\bin' )

[gjonespf]

Running Jenkins with Multibranch pipeline, similar to above cases.
Have had similar issues, and suggestions helped temporarily then continued to get build errors similar to above:

LibGit2Sharp.LibGit2SharpException: ref 'refs/remotes/origin/master' doesn't match the destination
  at LibGit2Sharp.Core.Ensure.HandleError (System.Int32 result) [0x00057] in <1a5aafd5a5444cd6a1420741ccbb6f8a>:0 

Found that the issues occurrend when PR and branch builds were using the same build directory, and branch builds would fail after a PR or vice versa. On a hunch, I added:

rm -Rf .git/gitversion_cache/

to start of build scripts, and problem disappeared. Anyone else have a similar result?

@theschnarr the first build, you can "Honour refspec on initial clone" - may help in your case.

[asbjornu]

Interesting find, @gjonespf. Is it not possible to tell Jenkins to clean the build directory on branch change? In TeamCity you can do that at least.

[gjonespf]

Have not fully confirmed this, but so far so good.
@asbjornu you certainly can, but it's not something I usually do due to time involved in larger builds. May be worth trying for others if it's a more viable option, and I've turned it on for some of my faster builds now to be safe. For multi branch it's under the check out behaviour, or you can code it in pipeline:

Oh, and curiously I can pop on the build agent and run GitVersion command line as same user in same dir, and it works fine also. Only difference I can see here is that I'm guessing the build branch is being fed in via env vars when it fails "Branch from build environment", e.g.:

INFO [08/16/18 16:56:28:09] Applicable build agent found: 'Jenkins'.
INFO [08/16/18 16:56:28:10] Branch from build environment: develop
ERROR [08/16/18 16:56:30:63] An unexpected error occurred:
LibGit2Sharp.LibGit2SharpException: ref 'refs/remotes/origin/feature/build-cleanup' doesn't match the destination

In this case it's failing on an old PR branch that isn't part of the intended build. Tho if I run the command line version with /b "develop", works fine..

[asbjornu]

Running from the command line without the magic environment variables being set by the build server, GitVersion won't run in its "build server" mode and will therefore follow another code path. For Jenkins, it seems like JENKINS_URL is the magic environment variable GitVersion is looking for:

https://github.com/GitTools/GitVersion/blob/fd0d71c7704a3ece6c25ed22b519f307c44891ff/src/GitVersionCore/BuildServers/Jenkins.cs#L11

Can you set that environment variable to trigger the "build server" mode and see whether you can reproduce the problem then, @gjonespf?

[graemevwilson]

I had this issue and also #1490 after setting Specify ref specs. I tried most of the suggestions above to no avail. What worked for me was in the job configuration under Branch Sources/Behaviours set Discover Branches to All Branches, set Fetch Tags under Advanced Clone Behaviours and lastly Checkout to matching local branch. I didn't need the Specify ref specs behaviour at all.

[JustinPullen]

We are using the Bitbucket Team/Project and hit this problem with 5.0.0 on Jenkins ver. 2.182.

What solved the error for us was the comment from @JonCubed here.

from memory, Jenkins does a shallow clone so only knows about the branch it is cloning. Have you tried fetch tags option in Advanced clone behaviours. If I remember correctly it shows checked event though it really should be unchecked and you have to uncheck, save -> check and save for it to work properly

I believe I should also note two other things.

1. We did not make any changes to the default ref specs.
2. We already had the same setup as @graemevwilson minus Fetch Tags or changing any ref specs. Comment here

I had this issue and also #1490 after setting Specify ref specs. I tried most of the suggestions above to no avail. What worked for me was in the job configuration under Branch Sources/Behaviours set Discover Branches to All Branches, set Fetch Tags under Advanced Clone Behaviours and lastly Checkout to matching local branch.

[queil]

EDIT: The below doesn't actually work, I had to add the following manual steps to make it work on non-master branches:

git checkout master
git checkout ${env.BRANCH_NAME}

---

I've faced the same issue with Jenkins 2.176.2 in a multi-branch pipeline using GitVersion 5.0.0.0 in the Mainline mode. The fix was to change my usual checkout scm to the following:

checkout([
                $class: 'GitSCM',
                branches: scm.branches,
                doGenerateSubmoduleConfigurations: scm.doGenerateSubmoduleConfigurations,
                extensions: scm.extensions + [[$class: 'LocalBranch']],
                userRemoteConfigs: scm.userRemoteConfigs
])

Essentially it just adds the LocalBranch module which is the equivalent of Checkout to matching local branch in the UI. Also it wouldn't work until I merged the change to master. Output of git branch --all must look similar to the following (rather than an info about a deatched HEAD):

* feature/test
  master
  remotes/origin/feature/test
  remotes/origin/master

[stale[bot]]

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.

[asbjornu]

@queil, correct – GitVersion needs the build to be performed from an actual branch and that at least master also exists in addition to the branch being built. Without those two pieces of information, GitVersion has no idea how to generate a version number. Perhaps we should have a fallback, but I don't know what that should be. Suggestions are welcome.

[queil]

@asbjornu Well, I think this is a problem with Jenkins, not GitVersion.

[asbjornu]

Yes, I agree, but it would be good if GitVersion was a bit more resilient to CI servers acting weird.

[stale[bot]]

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.

[Jasper-Ben]

For anyone using JCASC, add something along the lines of

cloneOptionTrait {
  extension {
    noTags(false)
    shallow(false)
    reference(null)
    timeout(10)
  }
}

to your "declarative-compatible traits".

[LeeShape]

We use jcasc but still face this error from time to time. Very annoying. Our codes:

cloneOptionTrait {
  extension {
    noTags(false)
    shallow(false)
    reference('')
    timeout(10)
    honorRefspec(false)
  }
}