3

I am using Jenkins with the plugin GitHub Pull Request Builder. I then have set up webhooks from GitHub to trigger a build in jenkins when a new Pull Request is opened or committed to.

I configured the GHPRB plugin with the Jenkins DSL:

job("name") {
    properties {
        githubProjectUrl("https://github.com/org/${repo}")
    }
    scm {
        git {
            remote {
                name("origin")
                url("git@github.com:org/${repo}.git")
                credentials("jenkins-ssh-keyid")
            }
            branch("**")
            extensions {
                gitTagMessageExtension()
            }
        }
    }
    triggers {
        githubPullRequest{
            admins(["github-username"])
            orgWhitelist('org-name')
            cron("")
            triggerPhrase("build")
            extensions {
                commitStatus {
                    context("unittest")
                }
            }
           useGitHubHooks()
       }
    }
    steps {
        shell("./run-unittests");
    }
}

The problem I am experiences is that sometimes Jenkins will get confused and pick the wrong commit to build on.

When that happens, the jenkins output looks like this:

GitHub pull request #9 of commit 126434b, no merge conflicts.
Setting status of 126434b to PENDING with url http://jenkins/job/unittest/26/ and message: 'Build started sha1 is merged.'
Using context: unittest
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url git@github.com:org/repo.git # timeout=10
Fetching upstream changes from git@github.com:org/repo.git
> git --version # timeout=10
using GIT_SSH to set credentials 
> git -c core.askpass=true fetch --tags --progress git@github.com:org/repo.git +refs/heads/*:refs/remotes/origin/*
Seen branch in repository origin/feature-branch-0
Seen branch in repository origin/feature-branch-1
Seen branch in repository origin/feature-branch-2
Seen 3 remote branches
Checking out Revision 1995d66 (origin/master)

Here, Jenkins goes from using the tip of the feature branch (126434b) to using the tip of master (1995d66) instead.

 > git config core.sparsecheckout # timeout=10
 > git checkout -f 1995d66
 > git rev-list ba7ec55 # timeout=10
 > git describe --tags 126434b # timeout=10
Tag information could not be determined for this revision; no git tag info will be exported

Notice that when Git Tag Message Plugin runs git describe to check for tag information, it is using the commit id for the feature branch.

Jenkins then goes on with the job, working on the master tip (1995d66), instead of the feature branch tip (126434b) as expected.

2

The problem was the branch specification and refspec. Changing the scm.git section of job to this solved the problem of Jenkins checking out the wrong commit:

scm {
    git {
        remote {
            name("origin")
            url("git@github.com:org/${repo}.git")
            credentials("jenkins-ssh-keyid")
            refspec('+refs/pull/*:refs/remotes/origin/pr/*')
            }
            branch('${ghprbActualCommit}')
        }
    }
}
  • Yes, the docs specify that the refspec needs to be that string - however, they also suggest setting branch to ${sha1} – Andrew Nov 8 '16 at 5:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.