Can you use the work around described in JENKINS-22694?

Register that user name and password in a credential, then use that credential in the job definition (rather than embedding the user name and password in the URL).

Alternately, can you use the work around of using an ssh URL to access that same repository instead of using an https URL?

Alternately, can you somehow include the username and password information in your downstream tasks using another technique?

Another possibility might be to try using JGit as the git implementation, instead of command line git.

As I stated in the bug I need to use this URL syntax, because of certain post build processors.

I tried the ssh URL and JGit, this are my test results:

Using JGit and https://
Failed to connect to repository : org.eclipse.jgit.errors.TransportException: https://username@bitbucket.org/user/repository.git: not authorized

Using JGit and git://
Failed to connect to repository : org.eclipse.jgit.errors.NotSupportedException: URI not supported: git://username@bitbucket.org/user/repository.git

Using JGit and ssh://
No error message, but the build runs in a endless loop.

Using Git command line and ssh://
Failed to connect to repository : Command "C:/Progra~2/Git/bin/git.exe -c core.askpass=true ls-remote -h ssh://username@bitbucket.org/user/repository.gitHEAD" returned status code 128:
stdout:
stderr: Unable to open connection:
Host does not existfatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists

I confirmed with git client plugin 1.16.1 and git plugin 2.3.5 that a private bitbucket repository with embedded user name and password fails to fetch. The remote.origin.url is correctly set in the workspace repository and is usable by "git remote update".

If I login to that slave, change directory to that repository and perform a "git remote update origin", the changes are fetched into the repository from the bitbucket URL.

I think that shows the problem is specific to a private bitbucket repository with https protocol and embedded user name and password from a Jenkins job. Change any one of those items (for example, use a credential instead of embedding the user name/password, or use a public bitbucket repository, or use a different protocol) and it seems to work. I realize none of those alternatives meet the needs of flaviodonze, but I now better understand the symptoms of the bug.

Also seeing this.
This may be a recurrence of this bug - JENKINS-20533.

nickcmaynard I don't think that it is a recurrence of JENKINS-20533, since that bug was fixed by deletion of a problematic code path, and that code path has definitely not been reintroduced.

Unfortunately, all that means is that I don't know where the bug is, only where it likely isn't.

I'm seeing this on a different host than Bitbucket - namely IBM's DevOps Services Git hosting.
The URLs for this look something like https://email%40domain.tld:password@hub.jazz.net/git/blah/blah

I've the same problem and in one case it appeared in jobs running on 'master'. What solved problem in this case was putting ssh key in <jenkins user home directory>/.ssh/id_rsa. So it seems it's a ssh access issue. What's bad - there are no records about the problem in jenkins log.

Now I have the second case. The same symptoms but on JClouds provided slaves and I wonder what should I do.

uvizhe I am surprised that you're having a problem which is specific to bitbucket and a username / password embedded directly in the URL. From other bug reports, it seems you're using GitHub Enterprise, not bitbucket.

Up to this time, I've only heard of this problem affecting bitbucket users, and only with the user name and password embedded directly into the URL.

If you resolved the issue by adding .ssh/id_rsa to the home directory of your Jenkins user, then you should also be able to use the Jenkins credentials plugin to insert that same private key into Jenkins, then reference that private key from the Git configuration within the specific job using that repository.

markewaite yes, I use GitHub Enterprise. I googled this bug and didn't see any other related to GitHub. Now I cannot reproduce the first case but in second I tried both anonymous repo fetching and specifying credentials (not directly in URL).

I already put my private key into Jenkins Credentials and it seems to work since I can execute buildsteps on JClouds slaves, but cannot fetch repo.

If there's GitHub related issue please point me to it. Thanks in advance.

uvizhe the problem you're describing with your environment is very different from the one described in this bug. This bug is specific to bitbucket, and specific to user name and password credentials embedded directly into the URL.

If the private key works for fetches to your JClouds slaves, then it seems like it should also work for any other slave, unless your JCloud slave has some environment setup which assures the git authentication will work (without using the private key).

I think you'll be better served by opening a new bug report rather than inserting your descriptions into this bug report.

Hi all,

I am seeing the same error with my BitBucket setup as well.

Using no checkout clone with sparse checkout.
Cloning repository https://bitbucket.org/****/****.git
> c:\Program Files (x86)\git\cmd\git.exe init c:\Jenkins\workspace**** # timeout=10
Fetching upstream changes from https://bitbucket.org/****/****.git
> c:\Program Files (x86)\git\cmd\git.exe --version # timeout=10
using .gitcredentials to set credentials
> c:\Program Files (x86)\git\cmd\git.exe config --local credential.helper store --file=\"C:\Users\ADMINI~1\AppData\Local\Temp\1\git774280159415349765.credentials\" # timeout=10
> c:\Program Files (x86)\git\cmd\git.exe -c core.askpass=true fetch --tags --progress https://bitbucket.org/****/****.git +refs/heads/:refs/remotes/origin/ # timeout=30
> c:\Program Files (x86)\git\cmd\git.exe config --local --remove-section credential # timeout=10
ERROR: Error cloning remote repo 'origin'
ERROR: Error cloning remote repo 'origin'

One thing to note is that it fails on a clean workspace (wipe clean) and works if I just retry the job again.

I am also getting a very similar issue using GIT plugin 2.3.5, GIT client plugin 1.17.1, and Jenkins 1.615:

Building remotely on somenode.net (label) in workspace c:\hudson\git-test
Cloning the remote Git repository
Cloning repository username@git-server:Category//subcategory.git
 > C:\hudson\tools\Git\ init c:\hudson\workspace\git-test # timeout=10
ERROR: Error cloning remote repo 'origin'
ERROR: Error cloning remote repo 'origin'
Finished: FAILURE

Seeing a similar issue sporadically using GIT plugin 2.3.5, GIT client plugin 1.17.1, and Jenkins 1.607 with Stash. Re-queuing the build has resolved the issue each time, but we were not seeing it when running 1.574 and earlier plugins prior to upgrading. I will review the logs and add any detail that I can find associated with the issue.

I'm having the same issue with a GitBlit repository using https. Re-queuing the build resolves the issue each time.
Jenkins version: 1.619
GIT client plugin 1.17.1
GIT plugin 2.3.5
Git Version 1.9.5-preview20150319

Code changed in jenkins
User: Mark Waite
Path:
src/test/java/org/jenkinsci/plugins/gitclient/CredentialsTest.java
http://jenkins-ci.org/commit/git-client-plugin/ff9c219277531dcf0f18dccd6d8665118e1827a3
Log:
Add username/password support to CredentialsTest

Help test JENKINS-26757, JENKINS-24368 and JENKINS-28460.

As far as I can tell from testing the most recent git client plugin (pre-release of 1.18.1) and the Jenkins 1.609.2 RC build, this is resolved for https://username:password@bitbucket.org/ private repositories. I believe Jacob Keller's recent submission has fixed this.

Bitbucket private repositories with ssh access still don't seem to work with username and password using that pre-release version.

Failed check. I had run that test interactively and thought it worked. An automated test is definitely working in my test harness. Unfortunately, when I just attempted the same thing from a fresh docker instance of Jenkins using https://username:password@bitbucket.org/username/private-repo.git, it failed. I then used the same repository URL from command line git and confirmed it works correctly.

The automated test must not be matching the real world closely enough. I'll explore further as time allows.

Hello All,

Also facing this error:

> D:\Programs\Git\cmd\git.exe -c core.askpass=true fetch --tags --progress ssh://*******.git +refs/heads/:refs/remotes/origin/*
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "D:\Programs\Git\cmd\git.exe -c core.askpass=true fetch --tags --progress ssh://************.git +refs/heads/:refs/remotes/origin/*" returned status code 128:
stdout:
stderr: plink: unknown option "-o"
plink: unknown option "-p"
fatal: Could not read from remote repository.

Please note: under Execute Windows batch command its OK
It only fails under GIT Plugin (Source Code Management)

This runs as slave:
GIT client plugin: 1.19.0
Git plugin: 2.4.0
Jenkins: v1.639

Best Regards,
Paulo

Paulo, can't you use a Jenkins managed credential which includes your bitbucket username and password? Then you don't need to embed the username and password in the URL, instead you let Jenkins keep the username and password better hidden.

Hi Mark, a am using the Jenkins managed credential, I didnt show the URL because its an internal URL. Therefore I don´t use the username and pass in the URL.
Thanks any way

If you're using a Jenkins managed credential, and you're using ssh protocol, then that is unrelated to this bug report. This bug requires that you are using http or https and that the username and password are embedded in the URL, not as a Jenkins managed credential.

I've never found a way to use username and password with an ssh protocol. I always need to use a private key for ssh protocol.

I've never found a way to use a private key with https protocol. I always need to use username and password for https protocol.

I just updated to Jenkins 2.0 Release Candidate. In the same move I updated "Git plugin" to version 2.4.4 and "Git client plugin" to version 1.19.6.
In this constellation the error does not occur anymore and the sources are cloned as expected.