Jenkins Error cloning remote repo 'origin', slave node Jenkins Error cloning remote repo 'origin', slave node windows windows

Jenkins Error cloning remote repo 'origin', slave node


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


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 JenkinsConfigure SystemUnder 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 projectSelect ConfigureUnder 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 rightRight-click and select "Properties" of the Jenkins Slave serviceSelect the "Log On" tabUpdate 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 exitRight-click again and select "Restart" to make the changes active.


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. Jenkins@company.local 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.