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

Git plugin doesn't use refspec on the first clone/fetch

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • git-plugin
    • None
    • Jenkins ver. 1.649
      Git plugin 2.4.2

      Our repositories have lots of references and we only need to build from a single branch from each job. For example, I have a job with refspec +refs/heads/master:refs/remotes/origin/master.

      On the first clone, it does the following:

      Cloning the remote Git repository
      Using shallow clone
      Avoid fetching tags
      Cloning repository https://github.com/foo.git
      > git init /tmp/jenkins/slave1/workspace/sample/smoke-test # timeout=10
      Fetching upstream changes from https://github.com/foo.git
      > git --version # timeout=10
      > git -c core.askpass=true fetch --no-tags --progress https://github.com/foo.git +refs/heads/*:refs/remotes/origin/* --depth=1 # timeout=10

          [JENKINS-33140] Git plugin doesn't use refspec on the first clone/fetch

          Eugene Timokhov added a comment -

          Duplicate https://issues.jenkins-ci.org/browse/JENKINS-31393

          Eugene Timokhov added a comment - Duplicate https://issues.jenkins-ci.org/browse/JENKINS-31393

          Mark Waite added a comment -

          Fixed in git plugin 2.5.1

          Mark Waite added a comment - Fixed in git plugin 2.5.1

          Javier Agüera added a comment -

          Hey,

          I'm getting the same exactly bug with version 3.0.5 and Jenkins: 2.32.2.

          The steps to reproduce the issue are the same.

          Is it possible to have a regression here?

          Thanks.

          Javier Agüera added a comment - Hey, I'm getting the same exactly bug with version 3.0.5 and Jenkins: 2.32.2. The steps to reproduce the issue are the same. Is it possible to have a regression here? Thanks.

          Mark Waite added a comment -

          What you're seeing is not a regression. It is an intentional choice that the default behavior had to remain compatible with the behavior which caused this bug report and JENKINS-31393.

          One or more use cases depended on the bug that the default initial fetch retrieved all refspecs, even if a refspec was provided. I was unable to find any way to make those use cases work other than to leave the default behavior as it was before this bug was fixed.

          Users who need to honor the refspec on initial clone will need to modify their job definition to add that to the job definition. The "Advanced clone behaviours" available in the "Add" button of the git plugin configuration section now includes a check box "Honor refspec on initial clone". You need to check that box for all jobs where you want to honor refspec on initial clone.

          Mark Waite added a comment - What you're seeing is not a regression. It is an intentional choice that the default behavior had to remain compatible with the behavior which caused this bug report and JENKINS-31393 . One or more use cases depended on the bug that the default initial fetch retrieved all refspecs, even if a refspec was provided. I was unable to find any way to make those use cases work other than to leave the default behavior as it was before this bug was fixed. Users who need to honor the refspec on initial clone will need to modify their job definition to add that to the job definition. The "Advanced clone behaviours" available in the "Add" button of the git plugin configuration section now includes a check box "Honor refspec on initial clone". You need to check that box for all jobs where you want to honor refspec on initial clone.

            Unassigned Unassigned
            ctran Cuong Tran
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: