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/CAO49JtEGUp308uKS3KO1L5bwWzZCjMcn62zRe7rT4vALywmLPg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
