[JIRA] (JENKINS-54612) Reference repo not used for Git clones on Windows SSH agents

4 views
Skip to first unread message

adam.brousseau88@gmail.com (JIRA)

unread,
Nov 13, 2018, 3:16:02 PM11/13/18
to jenkinsc...@googlegroups.com
Adam Brousseau created an issue
 
Jenkins / Bug JENKINS-54612
Reference repo not used for Git clones on Windows SSH agents
Issue Type: Bug Bug
Assignee: Mark Waite
Components: git-plugin
Created: 2018-11-13 20:15
Environment: Jenkins 2.138.2
Git Plugin 3.9.1
Windows 2012r2
Cygwin Git 2.17.0
Labels: windows git
Priority: Minor Minor
Reporter: Adam Brousseau

We use a reference repo on all our agents to speed up our clones. This seems to work on all agents we have except for our Windows nodes. I first noticed that the fetch times were slower on the Windows nodes. I then confirmed by checking the size of the .git folder on each machine after the clone. All non-windows nodes were 11MB whereas the .git folder on Windows was 1.9GB.

Our Windows agents are connected over ssh (Cygwin). The Remote Root is on C:\ (windows style path) and the reference repository is also on C:\. We use the Checkout/SCM pipeline step in order to take advantage of extra options not available using the Git step.

This is a simplified snippet of what we use I pulled from the Syntax generator.

checkout([
     $class: 'GitSCM',
     branches: [[name: '$BRANCH']],
     doGenerateSubmoduleConfigurations: false,
     extensions: [[$class: 'CloneOption',
         depth: 0,
         noTags: false,
         reference: '$REFERENCE_REPO',
         shallow: false]],
     gitTool: 'Default',
     submoduleCfg: [],
     userRemoteConfigs: [[url: '$REPO']]])

The console output tries to convince me it's using the reference repo but it appears it isn't (3:20 to fetch).

00:41:39.279 Cloning the remote Git repository
00:41:39.355 Cloning repository https://github.com/***/***.git
00:41:39.368  > git init C:\Users\jenkins\workspace\Build # timeout=10
00:41:39.574 Using reference repository: C:\repo_cache
00:41:39.574 Fetching upstream changes from https://github.com/***/***.git
00:41:39.574  > git --version # timeout=10
00:41:39.606  > git fetch --tags --progress https://github.com/***/***.git +refs/heads/*:refs/remotes/origin/* # timeout=30
00:45:00.369  > git config remote.origin.url https://github.com/***/***.git # timeout=10
00:45:00.431  > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
00:45:00.603  > git config remote.origin.url https://github.com/***/***.git # timeout=10
00:45:00.775 Fetching upstream changes from https://github.com/***/***.git
00:45:00.776  > git fetch --tags --progress https://github.com/***/***.git +refs/heads/*:refs/remotes/origin/* # timeout=30
00:45:02.416  > git rev-parse "origin/master^{commit}" # timeout=10
00:45:02.448 Checking out Revision *** (origin/master)
00:45:02.588  > git config core.sparsecheckout # timeout=10
00:45:02.619  > git checkout -f *** # timeout=30
00:46:45.479 Commit message: "Merge pull request #63 from ***/***"

I've tried various things like using Windows Git to populate the reference repo, using a Jenkins git step to populate the repo, using cygwin style paths for both the ref repo location and/or the remote root dir for the agent. Not sure what else I can try but I assume its going to be something related to windows vs cygwin vs path styles vs line-endings.

Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

mark.earl.waite@gmail.com (JIRA)

unread,
Nov 13, 2018, 4:16:01 PM11/13/18
to jenkinsc...@googlegroups.com
Mark Waite assigned an issue to Unassigned
Change By: Mark Waite
Assignee: Mark Waite

adam.brousseau88@gmail.com (JIRA)

unread,
Nov 13, 2018, 5:31:02 PM11/13/18
to jenkinsc...@googlegroups.com
Adam Brousseau updated an issue
Change By: Adam Brousseau
We use a reference repo on all our agents to speed up our clones. This seems to work on all agents we have except for our Windows nodes. I first noticed that the fetch times were slower on the Windows nodes. I then confirmed by checking the size of the .git folder on each machine after the clone. All non-windows nodes were 11MB whereas the .git folder on Windows was 1.9GB.

Our Windows agents are connected over ssh (Cygwin). The Remote Root is on C:\ (windows style path) and the reference repository is also on C:\. We use the Checkout/SCM pipeline step in order to take advantage of extra options not available using the Git step.

This is a simplified snippet of what we use I pulled from the Syntax generator.
{code:none}

checkout([
     $class: 'GitSCM',
     branches: [[name: '$BRANCH']],
     doGenerateSubmoduleConfigurations: false,
     extensions: [[$class: 'CloneOption',
         depth: 0,
         noTags: false,
         reference: '$REFERENCE_REPO',
         shallow: false]],
     gitTool: 'Default',
     submoduleCfg: [],
     userRemoteConfigs: [[url: '$REPO']]])
{code}

The console output tries to convince me it's using the reference repo but it appears it isn't (3:20 to fetch).
{code:none}

00:41:39.279 Cloning the remote Git repository
00:41:39.355 Cloning repository https://github.com/***/***.git
00:41:39.368  > git init C:\Users\jenkins\workspace\Build # timeout=10
00:41:39.574 Using reference repository: C:\repo_cache
00:41:39.574 Fetching upstream changes from https://github.com/***/***.git
00:41:39.574  > git --version # timeout=10
00:41:39.606  > git fetch --tags --progress https://github.com/***/***.git +refs/heads/*:refs/remotes/origin/* # timeout=30
00:45:00.369  > git config remote.origin.url https://github.com/***/***.git # timeout=10
00:45:00.431  > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
00:45:00.603  > git config remote.origin.url https://github.com/***/***.git # timeout=10
00:45:00.775 Fetching upstream changes from https://github.com/***/***.git
00:45:00.776  > git fetch --tags --progress https://github.com/***/***.git +refs/heads/*:refs/remotes/origin/* # timeout=30
00:45:02.416  > git rev-parse "origin/master^{commit}" # timeout=10
00:45:02.448 Checking out Revision *** (origin/master)
00:45:02.588  > git config core.sparsecheckout # timeout=10
00:45:02.619  > git checkout -f *** # timeout=30
00:46:45.479 Commit message: "Merge pull request #63 from ***/***"
{code}

I've tried various things like using Windows Git to populate the reference repo, using a Jenkins git step to populate the repo, using cygwin style paths for both the ref repo location and/or the remote root dir for the agent. Not sure what else I can try but I assume its going to be something related to windows vs cygwin vs path styles vs line-endings.


 

Edit: I can use an sh step to clone using the ref repo successfully.

dheeraj0060@gmail.com (JIRA)

unread,
Jan 17, 2019, 12:06:03 AM1/17/19
to jenkinsc...@googlegroups.com
dheeraj reddy commented on Bug JENKINS-54612
 
Re: Reference repo not used for Git clones on Windows SSH agents

I am also facing the exact issue(same environment also) while using git plugin (either as pipeline code or freestyle job).

Using cmd  or sh script I am able to clone it utilizing reference repo. 

May I know is there any bug on the git plugin ??

dheeraj0060@gmail.com (JIRA)

unread,
Jan 18, 2019, 4:16:02 AM1/18/19
to jenkinsc...@googlegroups.com

timor.raiman@gmail.com (JIRA)

unread,
May 16, 2019, 11:23:02 AM5/16/19
to jenkinsc...@googlegroups.com
Timor Raiman commented on Bug JENKINS-54612
 
Re: Reference repo not used for Git clones on Windows SSH agents

I'm seeing this with the pipeline only. (freestyle works).

 

vincenzo.melandri@gmail.com (JIRA)

unread,
Sep 23, 2019, 8:39:02 PM9/23/19
to jenkinsc...@googlegroups.com

I am seeing a similar problem, but with ubuntu agents.
It works with freestyle, but on declarative pipeline it doesn't work. It does not even try to load the reference repo for me.

This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages