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 <fakemailred...@gmail.com> 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 <slide...@gmail.com> 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 <fakemai...@gmail.com> 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 g...@bitbucket.org:myteam/myapp.git
>>>> > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
>>>> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
>>>> > git --version # timeout=10
>>>> using GIT_SSH to set credentials mygitcreds
>>>> > git fetch --tags --progress g...@bitbucket.org:myteam/myapp.git
>>>> +refs/heads/*:refs/remotes/origin/* # timeout=45
>>>> > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git #
>>>> timeout=10
>>>> > git config --add remote.origin.fetch
>>>> +refs/heads/*:refs/remotes/origin/* # timeout=10
>>>> > git config remote.origin.url g...@bitbucket.org:myteam/myapp.git #
>>>> timeout=10
>>>> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
>>>> using GIT_SSH to set credentials mygitcreds
>>>> > git fetch --tags --progress g...@bitbucket.org: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 g...@bitbucket.org:myteam/myapp.git
>>>> > git init C:\Jenkins\workspace\test-slave123456 # timeout=10
>>>> Fetching upstream changes from g...@bitbucket.org:myteam/myapp.git
>>>> > git --version # timeout=10
>>>> using GIT_SSH to set credentials mygitcreds
>>>> > git fetch --tags --progress g...@bitbucket.org: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
>>>> g...@bitbucket.org:myteam/myapp.git +refs/heads/*:refs/remotes/ori
>>>>
>>>> gin/*" returned status code 128:
>>>> stdout:
>>>> stderr: gituserfrom...@bitbucket.org: 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 jenkinsci-use...@googlegroups.com.
>>>
>>>
>>>> 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 jenkinsci-use...@googlegroups.com.
>>
>>
>>> 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 jenkinsci-users+unsubscr...@googlegroups.com.
> 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 jenkinsci-users+unsubscr...@googlegroups.com.
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.
