-
Bug
-
Resolution: Fixed
-
Major
-
Jenkins: 2.32.1
git plugin: 3.2.0
Whenever a new PR gets created and the first build that is executed with that PR it will fail 100% of the time with the following behavior:
At the end of the successful merge we get a NPE that is a result from the similarTo check that happens here (the recent change)
https://github.com/jenkinsci/git-plugin/commit/b8f94dfed07e996e87dff4f27615bc82ff8103c3#diff-f1f2ff967f38c8b53a4901be3169035eR1109
Here's my build log:
18:21:45 Wiping out workspace first. 18:21:45 Cloning the remote Git repository 18:21:45 Cloning repository git@code.espn.com:dp-ops/dp-jenkins-sandbox.git 18:21:45 > git init /var/lib/jenkins/workspace/ps_dp-jenkins-sandbox_PR-14-WU33IOH5B3HOCHSTNEOQ2GG7WJSK42NQPL2GSQDVQOCQ24WHHOEQ # timeout=10 18:21:45 Fetching upstream changes from git@code.espn.com:dp-ops/dp-jenkins-sandbox.git 18:21:45 > git --version # timeout=10 18:21:45 using GIT_SSH to set credentials Gadget-Gadget (gadget_id_rsa) 18:21:45 > git fetch --tags --progress git@code.espn.com:dp-ops/dp-jenkins-sandbox.git +refs/heads/*:refs/remotes/origin/* 18:21:46 > git config remote.origin.url git@code.espn.com:dp-ops/dp-jenkins-sandbox.git # timeout=10 18:21:46 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10 18:21:46 > git config remote.origin.url git@code.espn.com:dp-ops/dp-jenkins-sandbox.git # timeout=10 18:21:46 Fetching upstream changes from git@code.espn.com:dp-ops/dp-jenkins-sandbox.git 18:21:46 using GIT_SSH to set credentials Gadget-Gadget (gadget_id_rsa) 18:21:46 > git fetch --tags --progress git@code.espn.com:dp-ops/dp-jenkins-sandbox.git +refs/heads/*:refs/remotes/origin/* 18:21:46 > git config remote.origin1.url git@code.espn.com:dp-ops/dp-jenkins-sandbox.git # timeout=10 18:21:46 Fetching upstream changes from git@code.espn.com:dp-ops/dp-jenkins-sandbox.git 18:21:46 using GIT_SSH to set credentials Gadget-Gadget (gadget_id_rsa) 18:21:46 > git fetch --tags --progress git@code.espn.com:dp-ops/dp-jenkins-sandbox.git +refs/pull/*/head:refs/remotes/origin/pr/* 18:21:47 Merging master commit 81d267352ea18649976be512d0b510d549d8a4d5 into PR head commit dfe36150a1415afe6baaa266705babce0843a5d3 18:21:47 > git config core.sparsecheckout # timeout=10 18:21:47 > git checkout -f dfe36150a1415afe6baaa266705babce0843a5d3 18:21:47 > git merge 81d267352ea18649976be512d0b510d549d8a4d5 # timeout=10 18:21:47 > git rev-parse HEAD^{commit} # timeout=10 18:21:47 Merge succeeded, producing dfe36150a1415afe6baaa266705babce0843a5d3 [Pipeline] } [Pipeline] // stage [Pipeline] echo 18:21:47 Exception in pipeline: java.lang.NullPointerException [Pipeline] fileExists [Pipeline] stage [Pipeline] { (BuildFailure) [Pipeline] echo 18:21:47 Loading ./build-scripts/buildfailure.groovy
and finally the exception that we print
java.lang.NullPointerException at hudson.plugins.git.util.BuildData.normalize(BuildData.java:307) at hudson.plugins.git.util.BuildData.similarTo(BuildData.java:346) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1109) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:83) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:73) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47) at hudson.security.ACL.impersonate(ACL.java:221) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Finished: FAILURE
[JENKINS-43630] GitSCM: First Build on New PR fails
Code changed in jenkins
User: Mark Waite
Path:
src/test/java/hudson/plugins/git/util/BuildDataTest.java
http://jenkins-ci.org/commit/git-plugin/c3d75a6040fac1ee2c512fa78678a94af8751b62
Log:
Test to show JENKINS-43630
Code changed in jenkins
User: Mark Waite
Path:
src/main/java/hudson/plugins/git/util/BuildData.java
http://jenkins-ci.org/commit/git-plugin/44da1a460571f0af7ebb29a3610852cadd5b2514
Log:
Fix JENKINS-43630 - NPE if remote URL is null
Nothing to normalize if the remote URL is null.
Compare: https://github.com/jenkinsci/git-plugin/compare/12a77ddfd775...44da1a460571
Will be fixed in next release of git plugin. Pre-release build for verification available for a limited time from the ci.jenkins.io job in the "Build Artifacts" section.
Shawn Chasse
added a comment - Here's my checkout code
def performCheckout() {
// Mark the code checkout 'stage'....
stage ('Checkout Workspace') {
// Checkout code from the SCM
def result = checkout([
$class: 'GitSCM',
branches: scm.branches,
extensions: scm.extensions + [[$class: 'CleanCheckout'], [$class: 'PerBuildTag'], [$class: 'WipeWorkspace']],
userRemoteConfigs: scm.userRemoteConfigs + [name: 'origin']
])
return result
}
}
Beyond that we're using the github org folders to automatically create the jobs etc.
Shawn Chasse
added a comment - Here's my checkout code
def performCheckout() {
// Mark the code checkout 'stage' ....
stage ( 'Checkout Workspace' ) {
// Checkout code from the SCM
def result = checkout([
$class: 'GitSCM' ,
branches: scm.branches,
extensions: scm.extensions + [[$class: 'CleanCheckout' ], [$class: 'PerBuildTag' ], [$class: 'WipeWorkspace' ]],
userRemoteConfigs: scm.userRemoteConfigs + [name: 'origin' ]
])
return result
}
}
Beyond that we're using the github org folders to automatically create the jobs etc. I think that the
userRemoteConfigs: scm.userRemoteConfigs + [name: 'origin']
line is not doing what you want it to do. I believe the way the pipeline interprets that, it is adding an additional userRemoteConfig which defines only the name "origin" and does not define a repository for that userRemoteConfig. Can you describe the intent of that pipeline snippet?
Shawn Chasse
added a comment - I honestly forget how that became part of my standard checkout. I probably pulled it from an example somewhere when I started working on defining out pipeline. I can remove and see if that fixes it.
Shawn Chasse
added a comment - I honestly forget how that became part of my standard checkout. I probably pulled it from an example somewhere when I started working on defining out pipeline. I can remove and see if that fixes it. Shawn Chasse
added a comment - I removed the "+ [name: 'origin']" from the configuration and that did allow the first build to be successful.
Shawn Chasse
added a comment - I removed the "+ [name: 'origin'] " from the configuration and that did allow the first build to be successful. That's good news.
I created an integration test trying to confirm the problem. Unfortunately, that test does not show the problem. I understand how the problem occurs, I have a unit test which showed the problem, and I've committed the test and the fix. I would have liked the integration test to also show the problem, but I'll not worry about it further for now.
I am able to duplicate the bug with a unit test. It requires that I add a remote URL which is null. I am curious how your job is defined that it has a remote URL which is null. Can you provide more details on your job definition or your Jenkinsfile which might show how the remote URL of a repository is null?
I suspect that a null remote URL is not doing what you want, since the plugin can't clone from a repository that has a null remote URL. Possibly the URL definition has a trailing comma, or there is an additional repo defined which has an empty URL?
I'll submit a fix shortly.
I was unable to duplicate the problem on my initial interactive attempt. Steps I took: