Jenkins Error cloning remote repo 'origin', slave node

Asked 27/3, 2015 at 13:22 Answered 19/12, 2019 at 14:46

I need some help here, It's been a week I'm with this problem, can't figure out what's going on. I'm not able to clone a git repo from a slave node (Jenkins). I added the ssh key, host and slave (I've already tried generating a single key and one for each virtual and host)).

On Jenkins:

url:[email protected]: < repo>
Credentials: Here I tried with username/password, username with ssh file, username with ssh key directly, and -none-.

It doesn't seems like there is an authentication problem since I can clone the repo manually from console (both, slave and host). I can also connect with

ssh -T [email protected]

so the ssh key is fine, but when I build, this appear on console:

Building remotely on IE10Win7 in workspace C:\Users\IEUser\Desktop\< folder >

Wiping out workspace first.

Cloning the remote Git repository

Cloning repository [email protected]:< repo>.git

git init C:\Users\IEUser\Desktop\< folder> # timeout=10

ERROR: Error cloning remote repo 'origin'

ERROR: Error cloning remote repo 'origin'

Performing Post build task...

Does anyone have an idea? Hope someone can give me a clue, Thanks!

Evert answered 27/3, 2015 at 13:22 Comment(2)

I'm sorry I can't offer any help, but I'm definitely also looking forward to any input on this. I have the same problem on a Windows 7 (64) master trying to connect to a private repo. One job can not connect at all (with the above error), others all the time without problems, a few experience the error arbtrarily. – Squinty 16/4, 2015 at 11:33

I know this isn't a typical answer, but I had goofed and my builds were going to slave with incorrect credentials. Anyway, my $0.02 is to try it on another known good slave if these other solutions are falling short. – Swabber 20/9, 2016 at 22:54

I fixed this problem by setting the slave node tool path, selecting git and setting its value to

C:\Program Files (x86)\Git\bin\git.exe

Location: Configure Node - Tool Locations

Trundle answered 24/6, 2015 at 15:25 Comment(1)

this way's better as you don't need to change global jenkins configurations – Oleson 20/12, 2015 at 22:21

I recently updated several jenkins plugins and had this problem after the updates. Rolling back the git plugin didn't help, but I did a few other things to get it working. I listed all three here, but it was probably (2) that fixed the problem. Apparently the git executable was reset to default. So, configuring the git executable within the specific project was probably all that was needed. However the other items might come in handy too.

(1) The default git on a jenkins linux install geenrally points to /usr/lib... You need to specify a separate GitForWindows that points to the windows version:

Manage Jenkins
Configure System
Under Git - Git Installations
    Add Git -> Git
    Give it a name to be referenced in projects
      (mine is WindowsGit)
    Set Path to Git Executable
      (mine is "C:\Program Files (x86)\Git\bin\git.exe")
      (for recent git the path is "C:\Program Files\Git\bin\git.exe")

(2) Configure git on the specific project:

Select the project
Select Configure
Under Source Code Management - Git
    Select Git Executable as configured in 1)
    Set credentials or add new (ssh keys, etc)

(3) Updating the jenkins slave service to run as a specific user:

Go to Windows Services on the slave -- StartMenu, type "services"
Select the Jenkins Slave service in the list on the right
Right-click and select "Properties" of the Jenkins Slave service
Select the "Log On" tab
Update the username and password used in manual tests
    Domain login can be specificied with <DOMAIN>\<USERNAME>
    Local logins just use <USERNAME>
OK to save and exit
Right-click again and select "Restart" to make the changes active.

Darciedarcy answered 28/5, 2015 at 20:9 Comment(1)

I've followed the three steps, only after setting administrator rights on the jenkisn service it started working. – Dishtowel 23/10, 2015 at 17:3

I found a decent workaround in my case. The git clone command always inherits its process owner, which may make a difference, even if the two owners of Jenkins (SYSTEM) and cmd (USER) seem to have the same rights on your system. All other configurations were identical (keys, knownhosts, Git client version).

So as far as I can see, calling git clone from cmd will succeed because it calls the remote as USER, whereas git clone called from Jenkins may be rejected because it calls the remote as SYSTEM. In Services, where you would typically start Jenkins through the GUI, you can configure the service to run as a different user (right click on service --> Properties --> Log On). I had to put it like USER@DOMAIN, e.g. [email protected] or so. I'm not sure about how a cmd parameter would look, but I'd expect there to be one.

Also, I don't quite know what difference this workaround makes in the end, because on my Jenkins, SYSTEM and USER are configured to have the same rights across the system and they are of course both recognized as "Jenkins" by remote. Still, it does the trick for me. Deeper insights welcome.

Squinty answered 22/4, 2015 at 9:57 Comment(1)

The same thing happened to me again when I set up another Windows slave. It started after I installed the slave as a service ... That changes the user to SYSTEM. But I actually forgot that I had already put this answer here months ago, so I searched and wondered all over again x) – Squinty 22/12, 2015 at 10:8

I was facing similar problem and found that I need to add git to my PATH environment variable for a Windows based slave. I think that @dhj suggestion 2 might work as well in this case.

I found this workaround on Jenkins Jira.

Corney answered 12/6, 2015 at 10:34 Comment(0)

In my case, I started getting this exact error after updating Git on some of my build machines (via Chocolatey, using the "git.install" package) from 1.9.4 to 2.5.0. The old 1.9.4 install was a 32-bit package but the new one is a 64-bit one, so the default install location switched from C:\Program Files (x86)\Git to C:\Program Files\Git. I had the 64-bit path configured on the Jenkins master (since it had the newer Git version), but some slaves still had the older 32-bit version installed, so the slaves were attempting to use an incorrect path. I could have overridden the Git path for individual slaves but the cleaner solution for me was simply to upgrade all the slaves to the newer 64-bit version.

Tlingit answered 28/8, 2015 at 13:50 Comment(0)

I tried most of the above:

Specify git location. Set service user. Run as Administrator.

None of it worked. Eventually decided to uninstall git64 and install git32... changed the git path to the new location (in x86 Program Files). And everything worked.

Alliaceous answered 9/5, 2017 at 4:39 Comment(0)

I ran into this issue recently.

We had some items in our PATH EV which we had added when trying to connect Winium and Selenium to our Jenkins instance.

We removed these items, but still Jenkins seemed to be holding on to the values. After a bit of troubleshooting: restarting Jenkins; restarting the Jenkins server; setting the EVs at the node level; etc., we restarted the Jenkins JNLP service on the Windows slave.

And they lived happily ever after.

Marienthal answered 16/10, 2017 at 13:38 Comment(0)

I also got the same error and fixed by adding a git path in the "Manage Jenkins -> Global Tool Configuration".

In my env, The windows Jenkins master run a job on the ubuntu slave machine, the master machine has used the default git ('C:\Program Files\Git\git.exe') path and the slave machine has used the git ('/usr/bin/git') path, therefore, I configured slave git path into the master configuration '/usr/bin/git' and its start working for me

Barratry answered 19/12, 2019 at 14:46 Comment(0)

Recommended topics

Hot tags