• Type: Bug
• Resolution: Fixed
• Priority: Minor
• Component/s: git-plugin
• Labels:

  None
• Environment:

  Jenkins ver. 1.649
  Git plugin 2.4.2

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

Cuong Tran created issue - 2016-02-25 00:23

Cuong Tran made changes - 2016-02-25 00:24

Description

Original: 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

New: 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

Mark Waite made changes - 2016-03-05 22:57

Assignee

Original: Mark Waite [ markewaite ]

Collapse comment: Eugene Timokhov added a comment - 2016-04-16 22:33

Eugene Timokhov added a comment - 2016-04-16 22:33

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

Expand comment: Eugene Timokhov added a comment - 2016-04-16 22:33

Eugene Timokhov added a comment - 2016-04-16 22:33 Duplicate https://issues.jenkins-ci.org/browse/JENKINS-31393

Eugene Timokhov made changes - 2016-04-16 22:34

Resolution		New: Duplicate [ 3 ]
Status	Original: Open [ 1 ]	New: Closed [ 6 ]

Collapse comment: Mark Waite added a comment - 2016-07-02 00:34

Mark Waite added a comment - 2016-07-02 00:34

Fixed in git plugin 2.5.1

Expand comment: Mark Waite added a comment - 2016-07-02 00:34

Mark Waite added a comment - 2016-07-02 00:34 Fixed in git plugin 2.5.1

R. Tyler Croy made changes - 2016-07-26 00:01

Workflow

Original: JNJira [ 169013 ]

New: JNJira + In-Review [ 209746 ]

Collapse comment: Javier Agüera added a comment - 2017-03-03 12:32

Javier Agüera added a comment - 2017-03-03 12:32

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.

Expand comment: Javier Agüera added a comment - 2017-03-03 12:32

Javier Agüera added a comment - 2017-03-03 12:32 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 made changes - 2017-03-03 12:32

Resolution	Original: Duplicate [ 3 ]
Status	Original: Closed [ 6 ]	New: Reopened [ 4 ]

Collapse comment: Mark Waite added a comment - 2017-03-03 12:59

Mark Waite added a comment - 2017-03-03 12:59

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.

Expand comment: Mark Waite added a comment - 2017-03-03 12:59

Mark Waite added a comment - 2017-03-03 12:59 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 made changes - 2017-03-03 12:59

Link

New: This issue is related to JENKINS-31393 [ JENKINS-31393 ]

Mark Waite made changes - 2017-03-03 12:59

Resolution		New: Fixed [ 1 ]
Status	Original: Reopened [ 4 ]	New: Resolved [ 5 ]

Load more newer events