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

            ctran Cuong Tran created issue -
            ctran Cuong Tran made changes -
            Field Original Value New Value
            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
            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
            markewaite Mark Waite made changes -
            Assignee Mark Waite [ markewaite ]
            Show
            timocov Eugene Timokhov added a comment - Duplicate https://issues.jenkins-ci.org/browse/JENKINS-31393
            timocov Eugene Timokhov made changes -
            Status Open [ 1 ] Closed [ 6 ]
            Resolution Duplicate [ 3 ]
            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
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 169013 ] JNJira + In-Review [ 209746 ]
            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.
            javibm Javier Agüera made changes -
            Resolution Duplicate [ 3 ]
            Status Closed [ 6 ] Reopened [ 4 ]
            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.
            markewaite Mark Waite made changes -
            Link This issue is related to JENKINS-31393 [ JENKINS-31393 ]
            markewaite Mark Waite made changes -
            Status Reopened [ 4 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            markewaite Mark Waite made changes -
            Link This issue is related to JENKINS-36507 [ JENKINS-36507 ]
            dageissl Daniel Geißler made changes -
            Link This issue relates to JENKINS-28516 [ JENKINS-28516 ]
            markewaite Mark Waite made changes -
            Status Resolved [ 5 ] Closed [ 6 ]

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: