Having trouble with Git SCM checkout / cloning repository with multi-branch pipelines running on Windows agents

Using Jenkins
1

We are running Linux master with builds on Windows agents. Pulling from Git Bitbucket SCM repos

We are receiving errors when running our multi-branch pipelines using declarative Jenkinsfile
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
ERROR: Error cloning remote repo ‘origin’
hudson.plugins.git.GitException: Could not init D:\agent\workspace\xxxxxx

Caused by: java.io.IOException: Cannot run program “/usr/local/bin/git” (in directory “D:\agent\workspace\xxxxxx”): CreateProcess error=2, The system cannot find the file specified

We added the ‘checkout’ stage like so and even setup a tools configuration with a gitTools path

pipeline {
	agent {
		label 'zzzzz' 
	}
	tools { git 'gitpath' }
     steps {
                           checkout([
                                  $class: 'GitSCM',    
                                  gitTool: 'gitpath',
                                  branches: [[name: '*/xxxxx']],
                                  userRemoteConfigs: [[credentialsId: 'yyyyyyyyyyyyy', url: 'bbbbbbbbbbbbb']]
                           ])
                     }
              }

Still nothing seems to help…

2

The Jenkins agent tried to use the program /usr/local/bin/git as the git program. It could not find it. It could not find it because there is no program /usr/local/bin/git on your Windows agent.

Your choices are:

  • Enable JGit so that you don’t need to install git on Windows. This works well with repositories less than 50 MB. Repositories over 100MB are better handled by command line git
  • Install MinGit on your Windows agent and configure the PATH on the Windows agent so that it can find MinGit. The MinGit implementation is well suited to CI agent use cases. It does not have many of the user centered features of git for Windows
  • Install git for windows on the Windows agent and configure the PATH on the agent so that it can find Windows git
  • Define a global tool that will install MinGit on your Windows agent, then reference the tool in your Jenkinsfile
  • Define a global tool that will install git for Windows (or PortableGit), then reference the tool in your Jenkinsfile

My preferred solution is to install MinGit on the Windows agent so that I don’t waste time downloading the tool each time the agent is reset.

1 Like
3

Can you please fix your title, see On Jenkins Terminology Updates for details.

1 Like
4

For my systems, I have Git for Windows preinstalled and a global tool referencing the installed path on those Agents. You can also modify global Tools on a per-node basis to remap where they find tools like Git.

5

Mark, Thank you for the suggestions

We have Git for windows installed on the Windows agent under D:/Program Files (x86)/Git/bin/git.exe
and we have it configured in the PATH

We have also configured a GIT TOOL reference in Jenkins that I was showing being referenced in the Jenkinsfile

gitTool

but still it only wants to default to the Linux git path /usr/local/bin/git no matter what we try here

6

Don’t define the git tool in the checkout scm step and don’t define the tools section. If you’ve installed command line git and made it available on the agent’s PATH, then it can be called without requiring a gitTool: argument to checkout scm

7

Mark, We have installed the command line Git for Windows on the agent and it is defined on the agent’s PATH environment variable under D:\Program Files (x86)\Git\bin; I am able to call to Git.exe from anywhere on the agent including the Workspace.
This is what’s odd about this. It still keeps complaining about /usr/local/bin/git on a Windows agent when Git is installed and in the PATH

8

There is a new option in the Git plugin to automatically pick the best Git tool on your agents. Unfortunately it seems to pick a Linux path on Windows agents. I believe you can disable this new behaviour in the general Jenkins settings. (I don’t have access to a working Jenkins system right now but can verify this on Monday at work)

9

If you can describe steps to duplicate that behavior, I’m very interested. I use a Linux controller with Windows, Linux, FreeBSD, and OpenBSD and have not encountered a case where the Linux path is chosen on Windows agents.

10

Oh, this will be a good one to investigate then. As described by LeoB, I have a windows agent with Git for Windows pre-installed. The tool I’m using describes the path to the pre-installed Git on Linux. On my Windows node, I have overridden that tool with the path to the Git for Windows installation. With the Git plugin’s “Disable Performance Enhancements” checkbox unchecked, Jenkins seems to enforce the Linux path instead of the node’s override path.

I hope that’s enough to explain. I can verify settings when I get to work.

11

Hello again, yes we are still stuck running into this issue. We’ve tried everything , global tool, etc… Nothing seems to help as it continues to pick the Linux Git path over Windows Git path every time. If you can verify the exact settings and what you did to resolve, I would really appreciate your help on this.

Thank you
LeoB

12

The settings that I use are listed at

Those settings define multiple tool installers.

I use “git” as the path for the default git implementation rather than using “/usr/bin/git” (Linux specific) or “/usr/local/bin/git” (FreeBSD and OpenBSD) or “C:\Program Files.…” (Windows).

I prefer MinGit on Windows because it is smaller and is specifically designed for continuous integration and other non-interactive use cases.

13

Thanks, Mark.
I was asking @doofus_canadensis Ken since he mentioned running into a similar issue and possibly due to

The tool I’m using describes the path to the pre-installed Git on Linux. On my Windows node, I have overridden that tool with the path to the Git for Windows installation. With the Git plugin’s “Disable Performance Enhancements” checkbox unchecked, Jenkins seems to enforce the Linux path instead of the node’s override path.

14

FWIW, we have encountered a similar situation, but in the standard Pipeline project with a Linux agent.

Our setup is a brand new Jenkins v2.346.2 containerized deployment and a relatively unmodified Ubuntu 18.04 deployment with Git 2.37.1 (from ppa). Used the ‘typical’ plugin selection when initializing Jenkins, so whatever plugin manages the Pipeline SCM is up-to-date.

Enrolled the Ubuntu agent without any issues.

Pipeline Script (sh ‘git clone git@.git’) works without issue on the agent.
Switching to “Pipeline script from SCM” (with Jenkinsfile that just calls sh ‘env’) fails at cloning the repo (with and without skipDefaultCheckout).

Messages in the Console output always showed “The recommended git tool is: NONE” regardless of customizing the Git tool location for the agent. We verified (many times) the PATH and ENV values that were set for the agent, and nothing seemed out of the ordinary.

Based on this thread, we added a symlink on the agent (/usr/local/bin/git) which pointed to the tool’s actual location /usr/local/git and everything worked.

Strangely, in the console output, all of the repo cloning commands (now visible) showed /usr/local/git (vice /usr/local/bin/git). Seems to me that if the output’s logged commands were the actual ones being issued, then there is no reason why they fail when the symlink is not present.

We do not seem to have the “Disable Performance Enhancements” option in our Git Plugin configuration GUI (Global Tool Configuration?) so we cannot verify if this changes any behavior.

15

Hi @lbuchume
I too face same issue, what solution did you find to resolve this issue? I think your answer and solution applied is important to know how it was handled.
-Rani