The name of the temporary directory used for the credentials is based on either the workspace folder path (with @tmp appended) or the environment variables %TEMP% or %TMP%. If none of those contain a space character, then that is not the problem.
The plugin usually wirtes a message when it detects a space character in a temporary directory path. Since you didn't report such a message, I assume that is not the issue in this case. Mark Waite On Thu, May 10, 2018 at 12:38 PM red 888 <[email protected]> wrote: > 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]> 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]. >>> >> 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 > <https://groups.google.com/d/msgid/jenkinsci-users/1ab89567-36f1-4dc7-84a7-5dd90da4c2e8%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/CAO49JtFB6%2BD%3DvwSr4-CHMtbUQnenAmoqS_AKLX7GhLyPOQR0JA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
