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

Git fetch fails when "Branch Specifier" uses a parameter in new version of the Git plugin

      In a pipeline job from a git repository where the "Branch Specifier" is given as a parameter, I started getting the following failure after updating the git plugin.

      hudson.plugins.git.GitException: Command "git fetch --tags --progress origin +refs/heads/$\{GITREF}:refs/remotes/origin/$\{GITREF} --prune" returned status code 128:
      stdout: 
      stderr: fatal: Couldn't find remote ref refs/heads/$\{GITREF}
      
              at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1799)
              at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1525)
              at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:65)
              at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:316)
              at jenkins.plugins.git.GitSCMFileSystem$BuilderImpl.build(GitSCMFileSystem.java:304)
              at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:196)
              at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:172)
              at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:99)
              at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:59)
              at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:232)
              at hudson.model.ResourceController.execute(ResourceController.java:98)
              at hudson.model.Executor.run(Executor.java:404)
      Finished: FAILURE
      

      I have tested all released version of the git plugin from 3.0.1 to 3.2.0 and the failure seems to have appeared in 3.0.2.

      I don't know if it is relevant but with the Git plugin version 3.0.1, I see this at the beginning of the log:
      Lightweight checkout support not available, falling back to full checkout.
       

          [JENKINS-43818] Git fetch fails when "Branch Specifier" uses a parameter in new version of the Git plugin

          Grégoire Détrez created issue -
          Mark Waite made changes -
          Assignee Original: Mark Waite [ markewaite ]

          Mark Waite added a comment - - edited

          I'm unable to duplicate the problem you're reporting.  Please refer to my Jenkinsfile for the steps I'm using.

          Steps I took while trying to duplicate the problem:

          1. Copy JDK 8 tar file into my public_html/jdk directory
              $ mkdir -p ~/public_html/jdk/
              $ cp jdk-8u131-linux-*tar.gz ~/public_html/jdk/
            
          2. Copy the jenkins-bugs repo into a local bare repo for faster cloning later
              $ mkdir -p ~/git/bare/bugs/
              $ cd ~/git/bare/bugs/
              $ git clone --mirror https://github.com/MarkEWaite/jenkins-bugs
            
          3. Clone, build, and run the docker instance
              $ git lfs clone https://github.com/MarkEWaite/docker-lfs JENKINS-43818
              $ cd JENKINS-43818
              $ git lfs fetch origin origin/lts-with-plugins
              $ git checkout -b lts-with-plugins origin/lts-with-plugins
              $ docker build -t jenkins:JENKINS-43818 .
              $ VOL1=~/public_html:/var/jenkins_home/userContent/
              $ VOL2=~/git/bare:/var/lib/git/mwaite/
              $ docker run -i --rm --publish 8080:8080 --volume $VOL1 --volume $VOL2 jenkins:JENKINS-43687
            
          4. Connect a web browser to that docker instance (http://localhost:8080)
          5. Open the "Bugs - Pipeline Checks" folder
          6. Open the "jenkins-bugs" multi-branch pipeline job
          7. Click the "Scan Multibranch Pipeline" link and then the "Run Now" link to start branch indexing
          8. Confirm the JENKINS-43818 job runs successfully
          9. Confirm when I run the JENKINS-43818 job and give a parameter "master", it uses the master branch

          Mark Waite added a comment - - edited I'm unable to duplicate the problem you're reporting.  Please refer to my Jenkinsfile for the steps I'm using. Steps I took while trying to duplicate the problem: Copy JDK 8 tar file into my public_html/jdk directory $ mkdir -p ~/public_html/jdk/ $ cp jdk-8u131-linux-*tar.gz ~/public_html/jdk/ Copy the jenkins-bugs repo into a local bare repo for faster cloning later $ mkdir -p ~/git/bare/bugs/ $ cd ~/git/bare/bugs/ $ git clone --mirror https: //github.com/MarkEWaite/jenkins-bugs Clone, build, and run the docker instance $ git lfs clone https: //github.com/MarkEWaite/docker-lfs JENKINS-43818 $ cd JENKINS-43818 $ git lfs fetch origin origin/lts-with-plugins $ git checkout -b lts-with-plugins origin/lts-with-plugins $ docker build -t jenkins:JENKINS-43818 . $ VOL1=~/public_html:/ var /jenkins_home/userContent/ $ VOL2=~/git/bare:/ var /lib/git/mwaite/ $ docker run -i --rm --publish 8080:8080 --volume $VOL1 --volume $VOL2 jenkins:JENKINS-43687 Connect a web browser to that docker instance ( http://localhost:8080 ) Open the "Bugs - Pipeline Checks" folder Open the "jenkins-bugs" multi-branch pipeline job Click the "Scan Multibranch Pipeline" link and then the "Run Now" link to start branch indexing Confirm the JENKINS-43818  job runs successfully Confirm when I run the JENKINS-43818 job and give a parameter "master", it uses the master branch

          Thanks for looking at this. I am not using a multibranch pipeline but a simple pipeline job, where both the parameter and the git checkout are configured in the GUI, not in the jenkins file. I'll try to see if I can reproduce it in a docker image but I think that might already explain why the behavior is different in your experiment.

          Grégoire Détrez added a comment - Thanks for looking at this. I am not using a multibranch pipeline but a simple pipeline job, where both the parameter and the git checkout are configured in the GUI, not in the jenkins file. I'll try to see if I can reproduce it in a docker image but I think that might already explain why the behavior is different in your experiment.

          Denys Digtiar added a comment -

          gd13 Could you please give an example of git or checkout step that you use. Specifically, I am interested in what type of Groovy string you use in the `branch/branches` parameter. By default, snippet generator produces single quoted string which does not support string interpolation, therefore, the variable string you specify is used as is and not replaced by the variable value.

          Denys Digtiar added a comment - gd13 Could you please give an example of git or checkout step that you use. Specifically, I am interested in what type of Groovy string you use in the `branch/branches` parameter. By default, snippet generator produces single quoted string which does not support string interpolation, therefore, the variable string you specify is used as is and not replaced by the variable value.
          Grégoire Détrez made changes -
          Attachment New: Screenshot from 2017-03-28 17-14-05.png [ 37900 ]
          Grégoire Détrez made changes -
          Attachment New: Selection_001.png [ 37901 ]

          Grégoire Détrez added a comment - - edited

          duemir I don't use a checkout step, I configured both the git repo and the parameter in the "Configure" GUI. There GITREF is defined as a string parameter and in the "Branch Specifier" in the pipeline section, I simply wrote

          ${GITREF}
          

          Grégoire Détrez added a comment - - edited duemir I don't use a checkout step, I configured both the git repo and the parameter in the "Configure" GUI. There GITREF is defined as a string parameter and in the "Branch Specifier" in the pipeline section, I simply wrote ${GITREF}
          Grégoire Détrez made changes -
          Attachment Original: Screenshot from 2017-03-28 17-14-05.png [ 37900 ]

          Grégoire Détrez added a comment - - edited

          I just noticed on the screen shot the "Lightweight checkout" checkbox, I just tried un-checking it and re-installing 3.1.0 and it seems to work. This can be an other indication that the problem comes from the lightweight checkout.

          In any case this makes the problem less critical for us as it doesn't block us from updating plugins.

          Grégoire Détrez added a comment - - edited I just noticed on the screen shot the "Lightweight checkout" checkbox, I just tried un-checking it and re-installing 3.1.0 and it seems to work. This can be an other indication that the problem comes from the lightweight checkout. In any case this makes the problem less critical for us as it doesn't block us from updating plugins.

            Unassigned Unassigned
            gd13 Grégoire Détrez
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: