Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-43630

GitSCM: First Build on New PR fails

    Details

    • Similar Issues:

      Description

      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

        Attachments

          Activity

          Hide
          shawnchasse 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. 

          Show
          shawnchasse 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. 
          Hide
          markewaite Mark Waite added a comment -

          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?

          Show
          markewaite Mark Waite added a comment - 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?
          Hide
          shawnchasse 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.

          Show
          shawnchasse 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.
          Hide
          shawnchasse Shawn Chasse added a comment -

          I removed the "+ [name: 'origin']" from the configuration and that did allow the first build to be successful. 

          Show
          shawnchasse Shawn Chasse added a comment - I removed the "+ [name: 'origin'] " from the configuration and that did allow the first build to be successful. 
          Hide
          markewaite Mark Waite added a comment -

          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.

          Show
          markewaite Mark Waite added a comment - 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.

            People

            • Assignee:
              markewaite Mark Waite
              Reporter:
              shawnchasse Shawn Chasse
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: