12

i have a Jenkins multibranch Pipeline configured which should fetch sources from a remote GIT repository for a build. Jenkins no seems to "randomly" pick an old commit for the build an showing the message "Multiple candidate revisions" in Build log files.

My Pipeline is looking like:

checkout(
        [
            $class: 'GitSCM', 
            branches: [[name: "release/0.0.1"]],
            doGenerateSubmoduleConfigurations: false, 
            extensions: [
                [$class: 'MessageExclusion', excludedMessage: '(?s)^\\[DOC\\] Robot.*']
            ], 
            submoduleCfg: [], 
            userRemoteConfigs: [[credentialsId: 'xxx', url: "https://somerepo.net/scm/someproject/somecomponent.git"]]
        ]
    )

Log file from Jenkins shows:

[Pipeline] checkout
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://somerepo.net/scm/someproject/somecomponent.git # timeout=10
Fetching upstream changes from https://somerepo.net/scm/someproject/somecomponent.git
 > git --version # timeout=10
using GIT_ASKPASS to set credentials 
 > git fetch --tags --progress https://somerepo.net/scm/someproject/somecomponent.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse release/0.0.1^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/release/0.0.1^{commit} # timeout=10
Multiple candidate revisions
Checking out Revision 301c954e576bd3f03ef787563f159d541cb6e8d2 (release/0.0.1)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 301c954e576bd3f03ef787563f159d541cb6e8d2
Commit message: "Some old commit message"
 > git rev-list --no-walk 88be7349bd7b6ddb0654325e6b07cf1da2f8a35b # timeout=10

In the log file I can see that Jenkins is using the old revision 301c954e576bd3f03ef787563f159d541cb6e8d2 from release/0.0.1 instead of the new remote 88be7349bd7b6ddb0654325e6b07cf1da2f8a35b from refs/remotes/origin/release/0.0.1.

Any ideas whats going wrong here?

Russell Gallop
  • 1,631
  • 2
  • 17
  • 34
Frank Sehringer
  • 131
  • 1
  • 3

4 Answers4

5

I am not a git guru, but try specifying

branches: [[name: "*/release/0.0.1"]],

instead of

branches: [[name: "release/0.0.1"]],

user9656492
  • 51
  • 1
  • 1
    With that adaption it is working at least, but looks to me like a workaround. No I can see that Jenkins is checking: > git rev-parse refs/remotes/origin/release/0.0.1^{commit} # timeout=10 > git rev-parse refs/remotes/origin/origin/release/0.0.1^{commit} # timeout=10 The checking of refs/remotes/origin/origin/release/0.0.1 will then run into an error. – Frank Sehringer Apr 17 '18 at 18:23
1

I think that this could be related to the use of the LocalBranch option to git checkout. If you have previously used this in your workspace:

extensions: [
    [$class: 'LocalBranch', localBranch: "release/0.0.1"]
]

The Jenkins Git plugin will have checked out that branch locally (rather than just using the revision that referred to at the time). After that it will have a local branch that it can match before checking if that has new changes from upstream. It sounds like the guideline would be to use LocalBranch or not but changing between them could cause problems.

Russell Gallop
  • 1,631
  • 2
  • 17
  • 34
0

I had the same problem and "resolved" it by cleaning the workspace directory the hard way, like here. With the next run the problem was gone.

Side note: "Multiple candidate revisions" might be related to this issue.

crusy
  • 1,424
  • 2
  • 25
  • 54
0

In my case, I was using a custom workspace and removing the workspace manually but didn't remove the @tmp workspace dir, after removing both directories everything worked fine.

rm -rf $WORKSPACE*

Srinivasan M
  • 1
  • 2