also, if this is helpful this is the global git config on both slaves:

PS C:\Users\Administrator> git config --list
core.symlinks=false
core.autocrlf=true
core.fscache=true
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
help.format=html
rebase.autosquash=true
http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
http.sslbackend=openssl
diff.astextplain.textconv=astextplain
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true

On Thursday, May 10, 2018 at 2:22:10 PM UTC-4, Mark Waite wrote:
>
> Have you confirmed that the temporary directory on the failing machine 
> does not include any space characters in its path?  There is a known 
> problem on Windows that the credential passing technique required by 
> command line git does not allow a space character in the temporary 
> directory path.
>
> I assume from the log that the workspace does not include a space 
> character in its path.  If it does, that could invoke the same problem with 
> command line git authentication on Windows not really liking temporary 
> paths which contain a space character.
>
> Mark Waite 
>
> On Thu, May 10, 2018 at 12:17 PM red 888 <[email protected] 
> <javascript:>> wrote:
>
>> I can confirm the git ssh key works and has always worked so the creds 
>> themselves should not be an issue.
>>
>> git clone fails on both slaves (when run interactively as a logged in 
>> user). The windows task that runs the jnlp executes as the SYSTEM account.
>>
>> I also made sure to do git config --system --unset credential.helper. Any 
>> local config that would break this?
>>
>> The git jenkins plugin should be totally handling all the git cred setup 
>> stuff, but maybe someone modified a local config on the broken slave? the 
>> git global config looks identical on both of them
>>
>>
>> On Thursday, May 10, 2018 at 1:58:55 PM UTC-4, Mark Waite wrote:
>>
>>> It could be a "happy accident" that it is working on the first agent.  
>>>
>>> When using a command prompt on the first agent, does `git clone` allow 
>>> you to clone without prompting for remote username or password?  
>>>
>>> When using a command prompt on the second agent, does it behave the same 
>>> as the first agent?
>>>
>>> The login context (~/.ssh/ directory contents, environment variables, 
>>> etc.) affect agents which use that login context.  If the agent is already 
>>> configured to silently authenticate to bitbucket, then incorrect 
>>> credentials in the Jenkins environment are ignored and the repository is 
>>> still retrieved.
>>>
>>> Mark Waite
>>>
>>> On Thu, May 10, 2018 at 11:44 AM Slide <[email protected]> wrote:
>>>
>> Can you try dumping the environment variables on each node and see if 
>>>> there are any differences?
>>>>
>>>> On Thu, May 10, 2018 at 10:42 AM red 888 <[email protected]> wrote:
>>>>
>>> Super frustrating because this is working on one of my windows slaves, 
>>>>> but not this one- and I cant find any config differences.
>>>>>
>>>>> On the working slave I see this:
>>>>>
>>>>>
>>>>> [Pipeline] checkout
>>>>> Cloning the remote Git repository
>>>>> Cloning repository [email protected]:myteam/myapp.git
>>>>>  > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
>>>>> Fetching upstream changes from [email protected]:myteam/myapp.git
>>>>>  > git --version # timeout=10
>>>>> using GIT_SSH to set credentials mygitcreds
>>>>>  > git fetch --tags --progress [email protected]:myteam/myapp.git 
>>>>> +refs/heads/*:refs/remotes/origin/* # timeout=45
>>>>>  > git config remote.origin.url [email protected]:myteam/myapp.git # 
>>>>> timeout=10
>>>>>  > git config --add remote.origin.fetch 
>>>>> +refs/heads/*:refs/remotes/origin/* # timeout=10
>>>>>  > git config remote.origin.url [email protected]:myteam/myapp.git # 
>>>>> timeout=10
>>>>> Fetching upstream changes from [email protected]:myteam/myapp.git
>>>>> using GIT_SSH to set credentials mygitcreds
>>>>>  > git fetch --tags --progress [email protected]:myteam/myapp.git 
>>>>> +refs/heads/*:refs/remotes/origin/* # timeout=45
>>>>>  > git rev-parse "origin/test-slave^{commit}" # timeout=10
>>>>> Checking out Revision 30f11ef09ab13f73fb9a6b75983e1bf32437f51d 
>>>>> (origin/test-slave)
>>>>> Enabling Git LFS pull
>>>>>  > git config core.sparsecheckout # timeout=10
>>>>>  > git checkout -f 30f11ef09ab13f73fb9a6b75983e1bf32437f51d # timeout=45
>>>>>  > git config --get remote.origin.url # timeout=10
>>>>> using GIT_SSH to set credentials mygitcreds
>>>>>  > git lfs pull origin # timeout=45
>>>>> Commit message: "test slave"
>>>>>  > git rev-list --no-walk 30f11ef09ab13f73fb9a6b75983e1bf32437f51d # 
>>>>> timeout=10
>>>>>
>>>>>
>>>>>
>>>>> But on the failing slave:
>>>>>
>>>>>
>>>>> [Pipeline] checkout
>>>>> Cloning the remote Git repository
>>>>> Cloning repository [email protected]:myteam/myapp.git
>>>>>  > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
>>>>> Fetching upstream changes from [email protected]:myteam/myapp.git
>>>>>  > git --version # timeout=10
>>>>> using GIT_SSH to set credentials mygitcreds
>>>>>  > git fetch --tags --progress [email protected]:myteam/myapp.git 
>>>>> +refs/heads/*:refs/remotes/origin/* # timeout=45
>>>>> ERROR: Error cloning remote repo 'origin'
>>>>> hudson.plugins.git.GitException: Command "git fetch --tags --progress 
>>>>> [email protected]:myteam/myapp.git +refs/heads/*:refs/remotes/ori
>>>>>
>>>>> gin/*" returned status code 128:
>>>>> stdout: 
>>>>> stderr: [email protected]: Permission denied (publickey).
>>>>> fatal: Could not read from remote repository.
>>>>>
>>>>>
>>>>> Its the same pipeline job, same repo, same creds, and the slave should 
>>>>> be configured the same but when I change the agent to point to the other 
>>>>> slave it cant clone.
>>>>>
>>>>>
>>>>> On the working slave all i had to do was install git for windows (turn 
>>>>> off windows cred store), install java, and then run the jnlp jar.
>>>>>
>>>>>
>>>>> Tried to do the same thing on the non working slave so I dont know why 
>>>>> that one could be failing.
>>>>>
>>>> -- 
>>>>> 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/3afe4362-20f7-40c9-91ac-ac6573d0bd16%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/jenkinsci-users/3afe4362-20f7-40c9-91ac-ac6573d0bd16%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>> -- 
>>>> 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/CAPiUgVft0hmukqoCu-JQckBpj%3D72CwCfQp_tTwAz5kAvT_-qRg%40mail.gmail.com
>>>>  
>>>> <https://groups.google.com/d/msgid/jenkinsci-users/CAPiUgVft0hmukqoCu-JQckBpj%3D72CwCfQp_tTwAz5kAvT_-qRg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>> -- 
>> 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] <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/7127c010-253a-48c0-bf83-af218988a391%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-users/7127c010-253a-48c0-bf83-af218988a391%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/1ab89567-36f1-4dc7-84a7-5dd90da4c2e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to