Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-30927

'C:\Program' is not recognized as an internal or external command

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • git-client-plugin
    • None

      I tried to setup a test project, using a git project connecting through ssh.
      After selecting the ssh credential and adding the git URL (ssh://git@bitbucket.org/CLIENT/test.git) I get the following message:
      ---------------
      Failed to connect to repository : Command "C:/Progra~1/Git/bin/git.exe -c core.askpass=true ls-remote -h ssh://git@bitbucket.org/CLIENT/test.git HEAD" returned status code 128:
      stdout:
      stderr: 'C:\Program' is not recognized as an internal or external command,
      operable program or batch file.
      fatal: Could not read from remote repository.

      Please make sure you have the correct access rights
      and the repository exists.
      --------------

      My setup:
      Jenkins: 1.633
      GIT client plugin: 1.19.0
      GIT plugin: 2.4.0

      Jenkins Git Configuration is set to: C:/Progra~1/Git/bin/git.exe
      Git 2.6.1 from https://git-scm.com/downloads.

          [JENKINS-30927] 'C:\Program' is not recognized as an internal or external command

          Mark Waite added a comment -

          Are you certain that the git program is really in C:\Progra~1\Git\bin\git.exe, or is it in C:\Progra~2\Git\bin\git.exe (or some other differently named location)? For example, if you run a command prompt build step in a job which has no scm, can that command prompt build step execute the command "C:\Progra~1\Git\bin\git.exe"? Can it execute the command C:/Progra~1/Git/bin/git.exe?

          Have you tried specifying the location of the git executable with the spaces in the path to git, as in "C:\Program Files\Git\bin\git.exe"? That is the technique I use on most of my test and production machines and it works quite well.

          Is there a reason you feel you need to use the mangled form of the path rather than the form which includes spaces?

          Mark Waite added a comment - Are you certain that the git program is really in C:\Progra~1\Git\bin\git.exe, or is it in C:\Progra~2\Git\bin\git.exe (or some other differently named location)? For example, if you run a command prompt build step in a job which has no scm, can that command prompt build step execute the command "C:\Progra~1\Git\bin\git.exe"? Can it execute the command C:/Progra~1/Git/bin/git.exe? Have you tried specifying the location of the git executable with the spaces in the path to git, as in "C:\Program Files\Git\bin\git.exe"? That is the technique I use on most of my test and production machines and it works quite well. Is there a reason you feel you need to use the mangled form of the path rather than the form which includes spaces?

          Yes I'm sure the path is correct, I also tried:
          C:\Program Files\Git\bin\git.exe
          C:/Program Files/Git/bin/git.exe

          I switched to the mangled form because of the error message:
          stderr: 'C:\Program' is not recognized as an internal or external command,
          The message indicates that something is wrong with the path.

          Yes other paths work, e.g. https://.

          Flavio Donzé added a comment - Yes I'm sure the path is correct, I also tried: C:\Program Files\Git\bin\git.exe C:/Program Files/Git/bin/git.exe I switched to the mangled form because of the error message: stderr: 'C:\Program' is not recognized as an internal or external command, The message indicates that something is wrong with the path. Yes other paths work, e.g. https:// .

          Mark Waite added a comment - - edited

          If other git URLs work (like https://github.com/jenkinsci/git-client-plugin or git://github.com/jenkinsci/git-client-plugin.git/) then the likely problem is not in the git program itself, but in the attempt by the git plugin to run the ssh.exe program (or some other program) separately for authentication.

          There is a report in JENKINS-30045 which reports that two users were having problems with the git 2.5.0 version not being able to find the ssh.exe program.

          Is there anything else distinctive or unique about your git configuration?

          Mark Waite added a comment - - edited If other git URLs work (like https://github.com/jenkinsci/git-client-plugin or git://github.com/jenkinsci/git-client-plugin.git/) then the likely problem is not in the git program itself, but in the attempt by the git plugin to run the ssh.exe program (or some other program) separately for authentication. There is a report in JENKINS-30045 which reports that two users were having problems with the git 2.5.0 version not being able to find the ssh.exe program. Is there anything else distinctive or unique about your git configuration?

          Yes both https://github.com/jenkinsci/git-client-plugin and git://github.com/jenkinsci/git-client-plugin.git/ are working.

          Here some system variables, PATH I reduced to the relevant entries. I use the mangled form for most jenkins relevant entries, since I had path problems in the past.
          GIT_HOME = C:\Progra~1\Git\bin
          GIT_SSH = C:\Progra~1\Git\usr\bin\ssh.exe
          JAVA_HOME = C:\Progra~1\Java\jdk1.8.0_60
          PATH = C:\Progra~1\Java\jdk1.8.0_60\bin;C:\Progra~1\Java\jdk1.8.0_60\jre\bin\client;C:\Progra~1\TortoiseGit\bin;C:\Program Files\TortoiseGit\bin;C:\Progra~1\Git\bin;C:\Progra~1\Git\usr\bin

          The private ssh key is stored in: %USERPROFILE%\.ssh\id_rsa
          The public ssh key %USERPROFILE%\.ssh\id_rsa.pub is added in bitbucket.
          If I run "ssh -T git@bitbucket.org" in a cmd, I get the following output after entering the passphrase:
          logged in as USERNAME
          You can use git or hg to connect to Bitbucket. Shell access is disabled.

          I copied the value of the private key into jekins credential-store and added the passphrase.

          Flavio Donzé added a comment - Yes both https://github.com/jenkinsci/git-client-plugin and git://github.com/jenkinsci/git-client-plugin.git/ are working. Here some system variables, PATH I reduced to the relevant entries. I use the mangled form for most jenkins relevant entries, since I had path problems in the past. GIT_HOME = C:\Progra~1\Git\bin GIT_SSH = C:\Progra~1\Git\usr\bin\ssh.exe JAVA_HOME = C:\Progra~1\Java\jdk1.8.0_60 PATH = C:\Progra~1\Java\jdk1.8.0_60\bin;C:\Progra~1\Java\jdk1.8.0_60\jre\bin\client;C:\Progra~1\TortoiseGit\bin;C:\Program Files\TortoiseGit\bin;C:\Progra~1\Git\bin;C:\Progra~1\Git\usr\bin The private ssh key is stored in: %USERPROFILE%\.ssh\id_rsa The public ssh key %USERPROFILE%\.ssh\id_rsa.pub is added in bitbucket. If I run "ssh -T git@bitbucket.org" in a cmd, I get the following output after entering the passphrase: logged in as USERNAME You can use git or hg to connect to Bitbucket. Shell access is disabled. I copied the value of the private key into jekins credential-store and added the passphrase.

          Additional information, I now tried to create a ssh key without passphrase (just for testing), getting the same error.

          Flavio Donzé added a comment - Additional information, I now tried to create a ssh key without passphrase (just for testing), getting the same error.

          Mark Waite added a comment -

          Thanks for the additional information. It hints at several different areas which might be problems. Unfortunately, none of them seem likely (to me) to actually address the error message that is being reported.

          JENKINS-20879 reports that passphrase protected ssh keys don't work on Windows. There is a comment in that bug report which hints they might have worked at one time, but I spent several hours trying to find a way to make them work on Windows without success. My suspicion is that they never worked on Windows. There are even cases still today where they do not work on Linux.

          JENKINS-30755 reports that the GIT_HOME variable is not used in the git source code or in the git client plugin source code or in the git plugin source code. I don't think it will harm your installation, but as far as I can tell, it is unnecessary.

          JENKINS-20356 reports that a windows slave (or master) running as a service can't clone using an ssh private key. If Jenkins is running as a Windows service, I have little hope for you to be able to use ssh protected credentials.

          JENKINS-24368 and JENKINS-26757 report two different authentication problems that seem to be specific to bitbucket repositories.

          JENKINS-30045 reports a case where two users have a git 2.5.0 (and 2.6.0) installation on Windows that can't find ssh.exe. I haven't found (yet) what is different about their installation compared to the many installations I'm using of git 2.5.0 and git 2.6.0 for Windows, but they clearly have seen a problem.

          Have you attempted removing the Tortoise Git entries from your PATH, in case programs in those directories are returning different results than programs in the git distribution?

          Have you attempted to remove the GIT_SSH environment variable and instead allow the plugin to manage the value of GIT_SSH? There is code in the plugin that attempts several ways of guessing the correct value to assign to GIT_SSH.

          Are you using a Jenkins credential to define the credentials, or only relying on the private key stored in %USERPROFILE%\.ssh\id_rsa? The plugin has worked well for me using the Jenkins credentials system. I don't test with credentials stored locally in %USERPROFILE%\.ssh\id_rsa.

          Mark Waite added a comment - Thanks for the additional information. It hints at several different areas which might be problems. Unfortunately, none of them seem likely (to me) to actually address the error message that is being reported. JENKINS-20879 reports that passphrase protected ssh keys don't work on Windows . There is a comment in that bug report which hints they might have worked at one time, but I spent several hours trying to find a way to make them work on Windows without success. My suspicion is that they never worked on Windows. There are even cases still today where they do not work on Linux. JENKINS-30755 reports that the GIT_HOME variable is not used in the git source code or in the git client plugin source code or in the git plugin source code. I don't think it will harm your installation, but as far as I can tell, it is unnecessary. JENKINS-20356 reports that a windows slave (or master) running as a service can't clone using an ssh private key. If Jenkins is running as a Windows service, I have little hope for you to be able to use ssh protected credentials. JENKINS-24368 and JENKINS-26757 report two different authentication problems that seem to be specific to bitbucket repositories. JENKINS-30045 reports a case where two users have a git 2.5.0 (and 2.6.0) installation on Windows that can't find ssh.exe. I haven't found (yet) what is different about their installation compared to the many installations I'm using of git 2.5.0 and git 2.6.0 for Windows, but they clearly have seen a problem. Have you attempted removing the Tortoise Git entries from your PATH, in case programs in those directories are returning different results than programs in the git distribution? Have you attempted to remove the GIT_SSH environment variable and instead allow the plugin to manage the value of GIT_SSH? There is code in the plugin that attempts several ways of guessing the correct value to assign to GIT_SSH. Are you using a Jenkins credential to define the credentials, or only relying on the private key stored in %USERPROFILE%\.ssh\id_rsa? The plugin has worked well for me using the Jenkins credentials system. I don't test with credentials stored locally in %USERPROFILE%\.ssh\id_rsa.

          Flavio Donzé added a comment - - edited

          Thanks for your information and thoughts.

          I removed the GIT_SSH and the TortoiseGIT entries in the PATH variable. Same result, still getting the error.

          This is the log I get if I execute the build:

          Cloning repository ssh://git@bitbucket.org/CLIENT/test.git
          > C:/Progra~1/Git/bin/git.exe init DIRECTORY\test_ssh # timeout=10
          Fetching upstream changes from ssh://git@bitbucket.org/CLIENT/test.git
          > C:/Progra~1/Git/bin/git.exe --version # timeout=10
          using GIT_SSH to set credentials bitbucket nopass
          > C:/Progra~1/Git/bin/git.exe -c core.askpass=true fetch --tags --progress ssh://git@bitbucket.org/CLIENT/test.git +refs/heads/:refs/remotes/origin/
          ERROR: Error cloning remote repo 'origin'
          hudson.plugins.git.GitException: Command "C:/Progra~1/Git/bin/git.exe -c core.askpass=true fetch --tags --progress ssh://git@bitbucket.org/CLIENT/test.git +refs/heads/:refs/remotes/origin/" returned status code 128:
          stdout:
          stderr: 'C:\Program' is not recognized as an internal or external command,
          operable program or batch file.
          fatal: Could not read from remote repository.

          Please make sure you have the correct access rights
          and the repository exists.

          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1640)
          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1388)
          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:62)
          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:313)
          at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:505)
          at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1003)
          at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1043)
          at hudson.scm.SCM.checkout(SCM.java:485)
          at hudson.model.AbstractProject.checkout(AbstractProject.java:1277)
          at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610)
          at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
          at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532)
          at hudson.model.Run.execute(Run.java:1741)
          at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
          at hudson.model.ResourceController.execute(ResourceController.java:98)
          at hudson.model.Executor.run(Executor.java:408)
          ERROR: null
          Finished: FAILURE

          Interesting if I execute the commands, as printed in the log, in a normal CMD it works. I still don't know where the 'C:\Program' is coming from, since all my relevant paths are with ~.

          Flavio Donzé added a comment - - edited Thanks for your information and thoughts. I removed the GIT_SSH and the TortoiseGIT entries in the PATH variable. Same result, still getting the error. This is the log I get if I execute the build: Cloning repository ssh://git@bitbucket.org/CLIENT/test.git > C:/Progra~1/Git/bin/git.exe init DIRECTORY\test_ssh # timeout=10 Fetching upstream changes from ssh://git@bitbucket.org/CLIENT/test.git > C:/Progra~1/Git/bin/git.exe --version # timeout=10 using GIT_SSH to set credentials bitbucket nopass > C:/Progra~1/Git/bin/git.exe -c core.askpass=true fetch --tags --progress ssh://git@bitbucket.org/CLIENT/test.git +refs/heads/ :refs/remotes/origin/ ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Command "C:/Progra~1/Git/bin/git.exe -c core.askpass=true fetch --tags --progress ssh://git@bitbucket.org/CLIENT/test.git +refs/heads/ :refs/remotes/origin/ " returned status code 128: stdout: stderr: 'C:\Program' is not recognized as an internal or external command, operable program or batch file. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1640) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1388) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:62) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:313) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:505) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1003) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1043) at hudson.scm.SCM.checkout(SCM.java:485) at hudson.model.AbstractProject.checkout(AbstractProject.java:1277) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532) at hudson.model.Run.execute(Run.java:1741) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:408) ERROR: null Finished: FAILURE Interesting if I execute the commands, as printed in the log, in a normal CMD it works. I still don't know where the 'C:\Program' is coming from, since all my relevant paths are with ~.

          Yes I'm using Jenkins credentials, copied the private key into jenkins.

          Flavio Donzé added a comment - Yes I'm using Jenkins credentials, copied the private key into jenkins.

          Flavio Donzé added a comment - - edited

          I took a look at the code and tried to create the same handling outside of Jenkins:

          >> run.bat
          set GIT_SSH=C:\test_ssh\temp\ssh.bat
          set SSH_ASKPASS=C:\test_ssh\temp\pass.bat

          C:/Progra~1/Git/bin/git.exe init C:\test_ssh\workspace
          cd C:\test_ssh\workspace
          C:/Progra~1/Git/bin/git.exe -c core.askpass=true fetch --tags --progress ssh://git@bitbucket.org/CLIENT/test.git +refs/heads/:refs/remotes/origin/
          cd C:\test_ssh\temp

          >> ssh.bat
          @echo off
          "C:\Program Files\Git\usr\bin\ssh.exe" -i "C:\test_ssh\temp\ssh.key" -l "USER" -o StrictHostKeyChecking=no %*

          >> pass.bat
          echo ""

          >> key.ssh
          contains the private key

          And it worked....
          Then I tried to use an ssh key with passphrase, I had to enter it so looks like SSH_ASKPASS is being ignored.

          So I'm a bit clue less now, since it should work without passphrase.

          Flavio Donzé added a comment - - edited I took a look at the code and tried to create the same handling outside of Jenkins: >> run.bat set GIT_SSH=C:\test_ssh\temp\ssh.bat set SSH_ASKPASS=C:\test_ssh\temp\pass.bat C:/Progra~1/Git/bin/git.exe init C:\test_ssh\workspace cd C:\test_ssh\workspace C:/Progra~1/Git/bin/git.exe -c core.askpass=true fetch --tags --progress ssh://git@bitbucket.org/CLIENT/test.git +refs/heads/ :refs/remotes/origin/ cd C:\test_ssh\temp >> ssh.bat @echo off "C:\Program Files\Git\usr\bin\ssh.exe" -i "C:\test_ssh\temp\ssh.key" -l "USER" -o StrictHostKeyChecking=no %* >> pass.bat echo "" >> key.ssh contains the private key And it worked.... Then I tried to use an ssh key with passphrase, I had to enter it so looks like SSH_ASKPASS is being ignored. So I'm a bit clue less now, since it should work without passphrase.

          Interesting, if I remove the quotes from ssh.bat

          from
          @echo off
          "C:\Program Files\Git\usr\bin\ssh.exe" -i "C:\test_ssh\temp\ssh.key" -l "USER" -o StrictHostKeyChecking=no %*
          to
          @echo off
          C:\Program Files\Git\usr\bin\ssh.exe -i "C:\test_ssh\temp\ssh.key" -l "USER" -o StrictHostKeyChecking=no %*

          I get the same exception:
          'C:\Program' is not recognized as an internal or external command,
          operable program or batch file.
          fatal: Could not read from remote repository.
          Please make sure you have the correct access rights
          and the repository exists.

          But this can not be it, since I can see how the quotes are added in:
          org.jenkinsci.plugins.gitclient.CliGitAPIImpl.createWindowsGitSSH(File, String)
          Or could they be removed somewhere? Is the git command accessing other bat files?

          I tried to override the environment variable "ProgramFiles" with "C:/Progra~1" but failed. Tried -DProgramFiles= in the tomcat configuration, set the variable in windows and set it in jenkins configurations. Nothing worked.

          Flavio Donzé added a comment - Interesting, if I remove the quotes from ssh.bat from @echo off "C:\Program Files\Git\usr\bin\ssh.exe" -i "C:\test_ssh\temp\ssh.key" -l "USER" -o StrictHostKeyChecking=no %* to @echo off C:\Program Files\Git\usr\bin\ssh.exe -i "C:\test_ssh\temp\ssh.key" -l "USER" -o StrictHostKeyChecking=no %* I get the same exception: 'C:\Program' is not recognized as an internal or external command, operable program or batch file. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. But this can not be it, since I can see how the quotes are added in: org.jenkinsci.plugins.gitclient.CliGitAPIImpl.createWindowsGitSSH(File, String) Or could they be removed somewhere? Is the git command accessing other bat files? I tried to override the environment variable "ProgramFiles" with "C:/Progra~1" but failed. Tried -DProgramFiles= in the tomcat configuration, set the variable in windows and set it in jenkins configurations. Nothing worked.

          Mark Waite added a comment -

          I'm afraid I don't have any other ideas. I assume it must be somehow specific to your machine, or your environment, since there are over 20000 installations of git plugin 2.4.0 and this is the only report of that problem.

          Are you able to duplicate the problem on a fresh Windows machine using fewer environment variables and more of the default settings?

          Mark Waite added a comment - I'm afraid I don't have any other ideas. I assume it must be somehow specific to your machine, or your environment, since there are over 20000 installations of git plugin 2.4.0 and this is the only report of that problem. Are you able to duplicate the problem on a fresh Windows machine using fewer environment variables and more of the default settings?

          Todd Boyd added a comment -

          I just started receiving this error after upgrading my Git plugin. I have not upgraded Git itself or changed anything; just upgraded the plugin for Jenkins.

          Todd Boyd added a comment - I just started receiving this error after upgrading my Git plugin. I have not upgraded Git itself or changed anything; just upgraded the plugin for Jenkins.

          Mark Waite added a comment -

          tmboyd1, I suspect the case you're seeing has a very different condition than the one which Flavio encountered here. I suspect you'll need to fall back to the previous version of the git client plugin. Refer to JENKINS-43931 for more details on the problem I think you're seeing.

          I assume your case is using authenticated access to a git repository. Is it using a private key or a username / password pair?

          Mark Waite added a comment - tmboyd1 , I suspect the case you're seeing has a very different condition than the one which Flavio encountered here. I suspect you'll need to fall back to the previous version of the git client plugin. Refer to JENKINS-43931 for more details on the problem I think you're seeing. I assume your case is using authenticated access to a git repository. Is it using a private key or a username / password pair?

          Todd Boyd added a comment -

          Correct. I'm downgrading now to see if I can resolve it. Thanks for the link to the other bug report.

          Todd Boyd added a comment - Correct. I'm downgrading now to see if I can resolve it. Thanks for the link to the other bug report.

          Mark Waite added a comment -

          Are you using a private key or are you using a username / password.

          Mark Waite added a comment - Are you using a private key or are you using a username / password.

          Todd Boyd added a comment -

          We are using username/password. There is a space in our workspace folder names, so I'm 99% sure that's what is going on. They start with "C:\Program Files (x86)".

          Todd Boyd added a comment - We are using username/password. There is a space in our workspace folder names, so I'm 99% sure that's what is going on. They start with "C:\Program Files (x86)".

          Ryan Hinton added a comment - - edited

          Just starting receiving this error after upgrading and we have concluded it to be the same issue as Todd Boyd has explained above.  We currently cannot build using Jenkins at this time.  Is there an ETA when this will be fixed by chance?

          Thank you.

          Ryan Hinton added a comment - - edited Just starting receiving this error after upgrading and we have concluded it to be the same issue as Todd Boyd has explained above.  We currently cannot build using Jenkins at this time.  Is there an ETA when this will be fixed by chance? Thank you.

          Mark Waite added a comment - - edited

          hinton I suspect the case you're seeing has a very different condition than the one which Flavio encountered here. Flavio's case involved ssh based access to the repository, and private keys. tmboyd1's case used http/https based access to the repository with a username and password.

          I suspect you'll need to fall back to the previous version of the git client plugin for the short term. Refer to JENKINS-43931 for more details on the problem you're seeing.

          My most recent comment on JENKINS-43931 includes a link to a snapshot build of the git client plugin that you could also try if you'd rather not fall back to the previous version of the git client plugin.

          Mark Waite added a comment - - edited hinton I suspect the case you're seeing has a very different condition than the one which Flavio encountered here. Flavio's case involved ssh based access to the repository, and private keys. tmboyd1 's case used http/https based access to the repository with a username and password. I suspect you'll need to fall back to the previous version of the git client plugin for the short term. Refer to JENKINS-43931 for more details on the problem you're seeing. My most recent comment on JENKINS-43931 includes a link to a snapshot build of the git client plugin that you could also try if you'd rather not fall back to the previous version of the git client plugin.

          Ryan Hinton added a comment - - edited

          I downgraded the Git plugin and I am still receiving the problem.  There were a plethora of plugin upgrades that occurred at the same time.  Is it possible this could be caused by a different plugin?

          UPDATE: I just noticed your prompt reply, Mark. Thank you.  You mentioned Git Client plugin.  I downgraded the Git plugin.  I will downgrade Git Client plugin now.

          2nd UPDATE: I'm just confirming that after downgrading the Git Client plugin, my builds are operational, again.  I will look into the snapshots seeing that I am back to receiving a warning at the top of the Jenkins app.  Thank you for your assistance, Mark.

          Ryan Hinton added a comment - - edited I downgraded the Git plugin and I am still receiving the problem.  There were a plethora of plugin upgrades that occurred at the same time.  Is it possible this could be caused by a different plugin? UPDATE: I just noticed your prompt reply, Mark. Thank you.  You mentioned Git Client plugin.  I downgraded the Git plugin.  I will downgrade Git Client plugin now. 2nd UPDATE: I'm just confirming that after downgrading the Git Client plugin, my builds are operational, again.  I will look into the snapshots seeing that I am back to receiving a warning at the top of the Jenkins app.  Thank you for your assistance, Mark.

          Ed Sarrazin added a comment -

          I was fighting through this same issue today.  

          Failed to connect to repository : Command "git.exe ls-remote -h http://scm.abc.net:7990/scm/~blahapp-ui.git HEAD" returned status code -1:
          stdout: 
          stderr: 'D:\Apps\Tomcat\Tomcat' is not recognized as an internal or external command, 
          operable program or batch file.

          I thought it was a pathing issue to git as well, but I was seeing a partial path on the D:\Apps\Tomcat\Tomcat part of the error as well.  Turns out the installation for Tomcat 9 has spaces in it (D:\Apps\Tomcat\Tomcat 9.0).  What could be causing this when using the Git plugin?  Well their documentation says it needs write access to the temp directory, which defaulted to Tomcat 9.0\temp.  I went into the startup parameters of Tomcat and set the temp directory ( -Djava.io.tmpdir=d:\temp) and that fixed the error.  Looks like it is the spacing in the default install path.

          Git doc reference: https://wiki.jenkins.io/display/JENKINS/Git+Client+Plugin - under Gotchas

          Ed

          Ed Sarrazin added a comment - I was fighting through this same issue today.   Failed to connect to repository : Command "git.exe ls-remote -h  http://scm.abc.net:7990/scm/~blahapp-ui.git  HEAD" returned status code -1: stdout:  stderr: ' D:\Apps\Tomcat\Tomcat ' is not recognized as an internal or external command,  operable program or batch file. I thought it was a pathing issue to git as well, but I was seeing a partial path on the D:\Apps\Tomcat\Tomcat part of the error as well.  Turns out the installation for Tomcat 9 has spaces in it (D:\Apps\Tomcat\Tomcat 9.0).  What could be causing this when using the Git plugin?  Well their documentation says it needs write access to the temp directory, which defaulted to Tomcat 9.0\temp.  I went into the startup parameters of Tomcat and set the temp directory ( -Djava.io.tmpdir=d:\temp) and that fixed the error.  Looks like it is the spacing in the default install path. Git doc reference: https://wiki.jenkins.io/display/JENKINS/Git+Client+Plugin  - under  Gotchas Ed

          Mark Waite added a comment -

          chewy, I thought that a warning was printed by the plugin if it detected a space in the Windows temporary directory path.  Could you check the console output of one of your failing jobs to see if there is a warning about temporary directory names which contain ' '.

          You may also want to try git client plugin 2.4.6 which includes a fix for several workspace path related regressions that were introduced with the security fixes in git client plugin 2.4.4.

          Mark Waite added a comment - chewy , I thought that a warning was printed by the plugin if it detected a space in the Windows temporary directory path.  Could you check the console output of one of your failing jobs to see if there is a warning about temporary directory names which contain ' '. You may also want to try git client plugin 2.4.6 which includes a fix for several workspace path related regressions that were introduced with the security fixes in git client plugin 2.4.4.

          Ed Sarrazin added a comment -

          markewaite, We are on 2.4.6 and the problem is now resolved after setting the temp dir.  This was not in any console log of a job that I saw.  The polling log just ended with the "git.exe ls-remote -h........ # timeout 10" and no errors.  When polling the job, it just would never detect changes (we had a post commit hook added to solve, but that was a pain if 20 commits happened at once).  The only time we saw this error was configuring a job and you had to wait like 10 minutes for the error to show up in the designer.

          Ed Sarrazin added a comment - markewaite , We are on 2.4.6 and the problem is now resolved after setting the temp dir.  This was not in any console log of a job that I saw.  The polling log just ended with the "git.exe ls-remote -h........ # timeout 10" and no errors.  When polling the job, it just would never detect changes (we had a post commit hook added to solve, but that was a pain if 20 commits happened at once).  The only time we saw this error was configuring a job and you had to wait like 10 minutes for the error to show up in the designer.

          Mark Waite added a comment -

          chewy that says that the warning is not being made visible enough.  I'll need to investigate why that warning wasn't visible to you.

          The same problem hit me (and should have been detected by a warning), so it is worth some investigation.

          Mark Waite added a comment - chewy that says that the warning is not being made visible enough.  I'll need to investigate why that warning wasn't visible to you. The same problem hit me (and should have been detected by a warning), so it is worth some investigation.

          Ed Sarrazin added a comment -

          markewaite - Sure looks a lot like Flavios problem to me.  Hopefully this helps him too.

          Ed Sarrazin added a comment - markewaite - Sure looks a lot like Flavios problem to me.  Hopefully this helps him too.

          Sang B. Han added a comment -

          When ssh account with private certification fails to log in because id or password is wrong, it generate "stderr: 'C:\Program' is not recognized as an internal or external command, '" error message. Wrong error message is displayed.

           

          It's funny that the wrong credential is works in other place like Jenkinsfile. It fails only in scan pipeline. Because of that, it takes wrong time that i find the reason.

           

           

           

          Sang B. Han added a comment - When ssh account with private certification fails to log in because id or password is wrong, it generate "stderr: 'C:\Program' is not recognized as an internal or external command, '" error message. Wrong error message is displayed.   It's funny that the wrong credential is works in other place like Jenkinsfile. It fails only in scan pipeline. Because of that, it takes wrong time that i find the reason.      

            Unassigned Unassigned
            flaviodonze Flavio Donzé
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: