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

GitSCM: First Build on New PR fails

    XMLWordPrintable

Details

    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

          shawnchasse Shawn Chasse created issue -
          markewaite Mark Waite added a comment - - edited

          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:

          1. Define a GitHub Organization Folders job which monitors the MarkEWaite organization on github.com, watching the git-client-plugin repository
          2. Build the jobs that are defined
          3. Create a new pull request (PR17)
          4. Click the "Scan multi-branch pipeline" link in the git-client-plugin job, confirm that PR-17 is added as a job
          markewaite Mark Waite added a comment - - edited 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: Define a GitHub Organization Folders job which monitors the MarkEWaite organization on github.com, watching the git-client-plugin repository Build the jobs that are defined Create a new pull request ( PR17 ) Click the "Scan multi-branch pipeline" link in the git-client-plugin job, confirm that PR-17 is added as a job

          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

          scm_issue_link SCM/JIRA link daemon added a comment - 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

          scm_issue_link SCM/JIRA link daemon added a comment - 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
          markewaite Mark Waite added a comment - - edited

          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.

          markewaite Mark Waite added a comment - - edited 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.
          markewaite Mark Waite made changes -
          Field Original Value New Value
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Resolved [ 5 ]
          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. 

          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. 
          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?

          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?
          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.

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

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

          shawnchasse Shawn Chasse added a comment - I removed the "+ [name: 'origin'] " from the configuration and that did allow the first build to be successful. 
          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.

          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.
          markewaite Mark Waite made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

          People

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

            Dates

              Created:
              Updated:
              Resolved: