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

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

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: git-plugin
    • Labels:
      None
    • Environment:
      Jenkins ver. 1.649
      Git plugin 2.4.2
    • Similar Issues:

      Description

      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

        Attachments

          Issue Links

            Activity

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

            Show
            markewaite 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.
            Hide
            javibm 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.

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

            Fixed in git plugin 2.5.1

            Show
            markewaite Mark Waite added a comment - Fixed in git plugin 2.5.1
            Show
            timocov Eugene Timokhov added a comment - Duplicate https://issues.jenkins-ci.org/browse/JENKINS-31393

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: