Hi, thanks for your suggestion. I downgrade the git from 2.21.0 to 2.17.1 
(the version I used on the old machine) and anything work fine. I am 
wondering why the git version may cause issue of this kind.

On Monday, September 30, 2019 at 8:01:52 AM UTC+8, Mark Waite wrote:
>
>
>
> On Sun, Sep 29, 2019 at 5:12 PM Henry Xu  wrote:
>
>> I guess I have same issue. And it's wired as it works will on a machine I 
>> provisioned a year ago. Can you kindly provide more detail about how to 
>> using Global Tool Configuration to fix this problem? Thanks in advance.
>>
>>
> The Jenkins global tool configuration won't fix the problem, at least as 
> far as I know.
>
> If you have the same problem, then you are running Windows, have installed 
> cygwin, and have configured Jenkins to use the git program that is 
> available with cygwin.  The solution is to install git for Windows and 
> assure that it is the program which is used by Jenkins, instead of the git 
> program that is available with cygwin.  The Jenkins git plugin does not 
> test with the command line git version that is included with cygwin.  It 
> tests with git for Windows.
>
> Another alternative (for many use cases) is to enable JGit as a git 
> implementation in your Jenkins server, then configure the job to use JGit 
> instead of command line git.  JGit is able to run most use cases, but not 
> all use cases that are supported by command line git.  Refer to 
> https://plugins.jenkins.io/git-client for instructions to enable JGit in 
> your installation.
>  
>
>>
>> Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
>> --force --progress xxx +refs/heads/*:refs/remotes/Fiji/* --prune" returned 
>> status code 128:
>> stdout: 
>> stderr: error: cannot run c:\jws2\workspace\xxx\ssh7984855687134194056.bat: 
>> No such file or directory
>> fatal: unable to fork
>>
>>      at 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2042)
>>      at 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1761)
>>      at 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$400(CliGitAPIImpl.java:72)
>>      at 
>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:442)
>>      at 
>> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
>>      at 
>> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
>>      at hudson.remoting.UserRequest.perform(UserRequest.java:212)
>>      at hudson.remoting.UserRequest.perform(UserRequest.java:54)
>>      at hudson.remoting.Request$2.run(Request.java:369)
>>      at 
>> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
>>      at java.util.concurrent.FutureTask.run(Unknown Source)
>>      at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>>      at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>>      at java.lang.Thread.run(Unknown Source)
>>      Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to 
>> SDET-XMN160
>>              at 
>> hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1743)
>>              at 
>> hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
>>              at hudson.remoting.Channel.call(Channel.java:957)
>>              at 
>> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
>>              at sun.reflect.GeneratedMethodAccessor709.invoke(Unknown Source)
>>              at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>              at java.lang.reflect.Method.invoke(Method.java:498)
>>              at 
>> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
>>              at com.sun.proxy.$Proxy109.execute(Unknown Source)
>>              at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:892)
>>              at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
>>              at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
>>              at 
>> org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:120)
>>              at 
>> org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:90)
>>              at 
>> org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:77)
>>              at 
>> org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
>>              at 
>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>>              at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>              at 
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>              at 
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>              at java.lang.Thread.run(Thread.java:748)
>>
>>
>> On Wednesday, June 12, 2019 at 5:09:22 AM UTC+8, Giles wrote:
>>>
>>> Nailed it in one.
>>>
>>> I was sure it was a Jenkins issue ... but I'd upgraded Cygwin at the 
>>> same time, and that probably included their version of git.  Which yes, is 
>>> my default git.  I changed "Manage Jenkins" -> "Global Tool Configuration" 
>>> -> git to the just-installed "Git for Windows", and ... fixed.  I may have 
>>> to make some changes in the Jenkinsfiles themselves, but it seems clear now 
>>> that the latest Cygwin git broke something, and that Git for Windows fixed 
>>> it ...
>>>
>>> This was crisis-level breakage for my department - I can't thank you 
>>> enough.
>>>
>>> On Tuesday, 11 June 2019 16:36:38 UTC-4, Mark Waite wrote:
>>>>
>>>> Are you quite sure that your configuration did not change in about the 
>>>> same time as that upgrade?
>>>>
>>>> The log file indicates that you're running command line git as provided 
>>>> by Cygwin.  Is that intentional?  Has it always been that way?  
>>>>
>>>> I don't test the Jenkins git plugin with Cygwin.  I test with Git for 
>>>> Windows.  I'm glad cygwin git works, but don't intend to apply effort to 
>>>> make it work.
>>>>
>>>> I don't see anything suspicious or troubling in the list of updates.  
>>>> As far as I can tell, none of them should have changed that behavior of 
>>>> the 
>>>> git plugin.
>>>>
>>>> On Tue, Jun 11, 2019 at 1:54 PM Giles <[email protected]> wrote:
>>>>
>>>>> I'm running Jenkins 2.164.3 on a Windows server.  It's been running 
>>>>> well for several months.  Every Friday evening I do all the Jenkins 
>>>>> plugin 
>>>>> updates.  After this past Friday's updates (details below), all our jobs 
>>>>> are broken - apparently because the GitSCM checkout is broken.  Our 
>>>>> Jenkinsfiles are all stored in a git repo, so Jenkins attempts to pull a 
>>>>> new version before running the job.  This now fails.  I created a test 
>>>>> Jenkinsfile (editing directly in Jenkins rather than in the git repo) 
>>>>> with 
>>>>> this code in it:
>>>>>
>>>>>         def scmVars = checkout(
>>>>>             [
>>>>>                 $class: 'GitSCM',
>>>>>                 branches: [[name: '*/' + branch ]],
>>>>>                 doGenerateSubmoduleConfigurations: false,
>>>>>                 extensions: [],
>>>>>                 submoduleCfg: [],
>>>>>                 userRemoteConfigs: [
>>>>>                     [
>>>>>                         credentialsId: jenkinsCred,
>>>>>                         url: jenkinsRepo,
>>>>>                     ]
>>>>>                 ]
>>>>>             ]
>>>>>         );
>>>>>
>>>>> (Assume the "jenkinsCred" and "jenkinsRepo" values are correct.)  The 
>>>>> failure looks like this:
>>>>>
>>>>> [Pipeline] {[Pipeline] checkoutusing credential 
>>>>> 29d83033-ebf6-4811-9c45-b0aadec775c2
>>>>>  > C:\cygwin64\bin\git.exe rev-parse --is-inside-work-tree # timeout=10
>>>>> Fetching changes from the remote Git repository
>>>>>  > C:\cygwin64\bin\git.exe config remote.origin.url 
>>>>> [email protected]:*/*.git # timeout=10
>>>>> Fetching upstream changes from [email protected]:*/*.git
>>>>>  > C:\cygwin64\bin\git.exe --version # timeout=10
>>>>> using GIT_SSH to set credentials Read-only access to the "Jenkins" 
>>>>> repository at github.com/*.
>>>>>  > C:\cygwin64\bin\git.exe fetch --tags --force --progress 
>>>>> [email protected]:*/*.git +refs/heads/*:refs/remotes/origin/* # timeout=10
>>>>> ERROR: Error fetching remote repo 'origin'
>>>>> hudson.plugins.git.GitException: Failed to fetch from 
>>>>> [email protected]:*/*.git
>>>>>   at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:894)
>>>>>   at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1161)
>>>>>   at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
>>>>>   at 
>>>>> org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:120)
>>>>>   at 
>>>>> org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:90)
>>>>>   at 
>>>>> org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:77)
>>>>>   at 
>>>>> org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
>>>>>   at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
>>>>>   at java.util.concurrent.FutureTask.run(Unknown Source)
>>>>>   at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>>>>>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>>>>>   at java.lang.Thread.run(Unknown Source)
>>>>> Caused by: hudson.plugins.git.GitException: Command 
>>>>> "C:\cygwin64\bin\git.exe fetch --tags --force --progress 
>>>>> [email protected]:*/*.git +refs/heads/*:refs/remotes/origin/*" returned 
>>>>> status code 128:
>>>>> stdout: 
>>>>> stderr: error: cannot run 
>>>>> D:\Jenkins\workspace\DEBUG_07_git_Checkout@tmp\jenkins-gitclient-ssh1436722960383118000.bat:
>>>>>  No such file or directory
>>>>> fatal: unable to fork
>>>>>
>>>>>   at 
>>>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2318)
>>>>>   at 
>>>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1905)
>>>>>   at 
>>>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$400(CliGitAPIImpl.java:81)
>>>>>   at 
>>>>> org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:488)
>>>>>   at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:892)
>>>>>   ... 11 more[Pipeline] }[Pipeline] // node[Pipeline] End of 
>>>>> PipelineERROR: Error fetching remote repo 'origin'
>>>>> Finished: FAILURE
>>>>>
>>>>> This is essentially identical to the failure we're seeing for all jobs.  
>>>>> I assume it's normal behaviour that GitSCM generates and
>>>>> tries to run a random-named bat file?  It's unclear to me if the bat file 
>>>>> isn't created or is unreadable, although Jenkins is running
>>>>> as SYSTEM and has generally been able to read and write everything.
>>>>>
>>>>> Does anyone have any thoughts on what may have gone wrong?
>>>>>
>>>>>      -----
>>>>>
>>>>>
>>>>> The updates made Friday night:
>>>>>
>>>>> >>> Artifactory 3.2.2 -> 3.2.4  [ security warning 
>>>>> ]                            
>>>>> >>> Pipeline: API 2.34 -> 
>>>>> 2.35                                                  
>>>>> >>> Pipeline: Basic Steps 2.16 -> 
>>>>> 2.18                                          
>>>>> >>> Pipeline: Declarative 1.3.8 -> 
>>>>> 1.3.9                                        
>>>>> >>> Pipeline: Declarative Extension Points API 1.3.8 -> 
>>>>> 1.3.9                   
>>>>> >>> Pipeline: Groovy 2.69 -> 
>>>>> 2.70                                               
>>>>> >>> Pipeline: Model API 1.3.8 -> 
>>>>> 1.3.9                                                                     
>>>>>   
>>>>> >>> Pipeline: Nodes and Processes 2.30 -> 
>>>>> 2.31                                                                
>>>>> >>> Pipeline: SCM Step 2.7 -> 
>>>>> 2.9                                                         
>>>>> >>> Pipeline: Stage Tags Metadata 1.3.8 -> 
>>>>> 1.3.9                                
>>>>> >>> Pipeline: Step API 2.19 -> 
>>>>> 2.20                                                       
>>>>> >>> Slack Notification 2.23 -> 2.24
>>>>>
>>>>> I've since rolled back all of the "Pipeline: ..." changes.  The 
>>>>> problem didn't change.
>>>>>
>>>>> About 40 Cygwin updates (I didn't enumerate those.)
>>>>>
>>>>> -- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "Jenkins Users" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>> an email to [email protected].
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/jenkinsci-users/2d7c0927-22ba-4443-8121-0867169df831%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/2d7c0927-22ba-4443-8121-0867169df831%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>> -- 
>>>> Thanks!
>>>> Mark Waite
>>>>
>>> -- 
>>
>
> -- 
> Thanks!
> Mark Waite
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/6440ee7e-354d-4362-b6a2-77c59deb714f%40googlegroups.com.

Reply via email to