[JIRA] [git-plugin] (JENKINS-26680) Extraneous Forward-Slash in ssh:// path to repository

16 views
Skip to first unread message

jerome@oufella.com (JIRA)

unread,
Dec 31, 2015, 11:25:02 AM12/31/15
to jenkinsc...@googlegroups.com
Jerome Oufella commented on Bug JENKINS-26680
 
Re: Extraneous Forward-Slash in ssh:// path to repository

The bug does not only manifest itself when using relative repositories, but also when using variables to compose a git URI. For example with the Gerrit plugin, you may want to use a git uri such as ssh://$GERRIT_HOST:$GERRIT_PORT/$GERRIT_PROJECT. In this case, the URI will be rewritten with a triple slash, leading to a failure with most git distributions.
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
Atlassian logo

mark.earl.waite@gmail.com (JIRA)

unread,
Dec 31, 2015, 11:44:03 AM12/31/15
to jenkinsc...@googlegroups.com

Jerome Oufella I don't understand how the rewrite is happening in your case, since you're using the platform portable form of the URL (assuming GERRIT_PORT is either a port number or the name of a port as listed in /etc/services). The other entries in this bug report are asking for a URI syntax which is not platform portable, but as far as I can tell, your URI syntax is platform portable.

Are you sure that your case $GERRIT_PORT actually is evaluating to a port number?

jerome@oufella.com (JIRA)

unread,
Dec 31, 2015, 11:52:02 AM12/31/15
to jenkinsc...@googlegroups.com

Hi Mark Waite, yes I can confirm that from the job instance's console log. As you can see below, the URL is rewritten using an extra slash.

Job's git repository URL: ssh://$GERRIT_HOST:$GERRIT_PORT/$GERRIT_PROJECT
Result:
{{
...
Fetching upstream changes from ssh:///obfuscatedhostname.com:29419/some/repo
> git --version # timeout=10
> git -c core.askpass=true fetch --tags --progress ssh:///obfuscatedhostname.com:29419/some/repo +refs/heads/:refs/remotes/origin/
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress ssh:///obfuscatedhostname.com:29419/some/repo +refs/heads/:refs/remotes/origin/" returned status code 128:
stdout:
stderr: ssh: Could not resolve hostname : Name or service not known
fatal: Could not read from remote repository.
...
}}

jerome@oufella.com (JIRA)

unread,
Dec 31, 2015, 11:53:01 AM12/31/15
to jenkinsc...@googlegroups.com
Jerome Oufella edited a comment on Bug JENKINS-26680
Hi [~markewaite], yes I can confirm that from the job instance's console log. As you can see below, the URL is rewritten using an extra slash.


Job's git repository URL: ssh://$GERRIT_HOST:$GERRIT_PORT/$GERRIT_PROJECT
Result:
{ { code}
...
Fetching upstream changes from ssh:///obfuscatedhostname.com:29419/some/repo
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress ssh:///obfuscatedhostname.com:29419/some/repo +refs/heads/*:refs/remotes/origin/*

ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress ssh:///obfuscatedhostname.com:29419/some/repo +refs/heads/*:refs/remotes/origin/*" returned status code 128:

stdout: 
stderr: ssh: Could not resolve hostname : Name or service not known
fatal: Could not read from remote repository.
...
{code } }

EDIT: fix code block

jerome@oufella.com (JIRA)

unread,
Dec 31, 2015, 11:58:02 AM12/31/15
to jenkinsc...@googlegroups.com
Jerome Oufella edited a comment on Bug JENKINS-26680
Hi [~markewaite], yes I can confirm that from the job instance's console log. As you can see below, the URL is rewritten using an extra slash.

Job's git repository URL: ssh://$GERRIT_HOST:$GERRIT_PORT/$GERRIT_PROJECT
Result:
{code :none }

...
Fetching upstream changes from ssh:///obfuscatedhostname.com:29419/some/repo
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress ssh:///obfuscatedhostname.com:29419/some/repo +refs/heads/*:refs/remotes/origin/*
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress ssh:///obfuscatedhostname.com:29419/some/repo +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: ssh: Could not resolve hostname : Name or service not known
fatal: Could not read from remote repository.
...
{code}

EDIT: fix code block

jerome@oufella.com (JIRA)

unread,
Dec 31, 2015, 12:05:02 PM12/31/15
to jenkinsc...@googlegroups.com

Note, this was tested with the following configuration:

  • Jenkins 1.643
  • Git plugin 2.4.1
  • Git client plugin 1.19.1

mark.earl.waite@gmail.com (JIRA)

unread,
Dec 31, 2015, 12:10:03 PM12/31/15
to jenkinsc...@googlegroups.com

Thanks for the further clarification. I think I see the same condition you're seeing in my test job.

If I create a test URI that includes the port number (like ssh://wheezy64b.markwaite.net:45022/var/lib/git/mwaite/bin.git) then the clone works.

If I create a parameterized test job with PORT_NUMBER as the parameter and assign it a value of 45022, and reference that port number in the URL, then the clone fails. It is as though the rewrite is somehow involved in the code path that expands that parameter.

mark.earl.waite@gmail.com (JIRA)

unread,
Jul 12, 2018, 4:57:03 PM7/12/18
to jenkinsc...@googlegroups.com

If the issue truly is in the JGit dependency, then git client plugin 3.0.0-beta versions (available now from the experimental update center) should have it fixed. They include a newer version of JGit and that newer version should include the fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=519187
This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)

nicolas.deloof@gmail.com (JIRA)

unread,
Apr 24, 2019, 10:30:29 AM4/24/19
to jenkinsc...@googlegroups.com
Nicolas De Loof assigned an issue to Unassigned
 
Jenkins / Bug JENKINS-26680
Change By: Nicolas De Loof
Assignee: Nicolas De Loof
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

anonymousaccounts@icloud.com (JIRA)

unread,
Dec 16, 2019, 3:44:04 PM12/16/19
to jenkinsc...@googlegroups.com
a b commented on Bug JENKINS-26680
 
Re: Extraneous Forward-Slash in ssh:// path to repository

I am experiencing this issue and cannot figure out how to work around it.  Attempting to use the following syntax to checkout a repo in a declarative pipeline job. It adds the extra slash when using the ssh:// prefix and fails another way without it. Are there other options?

dir("testing-workspace/") {
  git branch: 'master',
  credentialsId: 'bitbucket_ssh',
  url: 'ssh://g...@bitbucket.org:<company>/<repo_name>.git'
}                    }

 
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

anonymousaccounts@icloud.com (JIRA)

unread,
Dec 16, 2019, 3:45:02 PM12/16/19
to jenkinsc...@googlegroups.com
a b edited a comment on Bug JENKINS-26680
I am experiencing this issue and cannot figure out how to work around it.  Attempting to use the following syntax to checkout a repo in a declarative pipeline job. It adds the extra slash when using the ssh:// prefix and fails another way without it. Are there other options?
{code:java}

dir("testing-workspace/") {
  git branch: 'master',
  credentialsId: 'bitbucket_ssh',
  url: 'ssh://g...@bitbucket.org:<company>/<repo_name>.git'
}                     } {code}
 

anonymousaccounts@icloud.com (JIRA)

unread,
Dec 16, 2019, 3:47:03 PM12/16/19
to jenkinsc...@googlegroups.com
a b edited a comment on Bug JENKINS-26680
I am experiencing this issue and cannot figure out how to work around it.  Attempting to use the following syntax to checkout a repo in a declarative pipeline job. It adds the extra slash when using the ssh:// prefix and fails another way without it. Are there other options?
{code:java}
dir("testing-workspace/") {
  git branch: 'master',
  credentialsId: 'bitbucket_ssh',
  url: 'ssh://g...@bitbucket.org:<company>/<repo_name>.git'
}{code}
  Error (sensitive data obfuscated)

 
{code:java}
ssh:///g...@bitbucket.org:****/******.git

+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout:
stderr: ssh: Could not resolve hostname : Name or service not known
fatal: Could not read from remote repository.
{code}
 

anonymousaccounts@icloud.com (JIRA)

unread,
Dec 16, 2019, 3:49:03 PM12/16/19
to jenkinsc...@googlegroups.com
a b edited a comment on Bug JENKINS-26680
I am experiencing this issue and cannot figure out how to work around it.  Attempting to use the following syntax to checkout a repo in a declarative pipeline job. It adds the extra slash when using the ssh:// prefix and fails another way without it. Are there other options?
{code:java}
dir("testing-workspace/") {
  git branch: 'master',
  credentialsId: 'bitbucket_ssh',
  url: 'ssh://g...@bitbucket.org:<company>/<repo_name>.git'
}{code}
 Error (sensitive data obfuscated)

 
{code:java}
ssh:///g...@bitbucket.org:****/******.git
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout:
stderr: ssh: Could not resolve hostname : Name or service not known
fatal: Could not read from remote repository.
{code}
Jenkins: 2.207

Git plugin:   4.0.0

mark.earl.waite@gmail.com (JIRA)

unread,
Dec 16, 2019, 4:03:03 PM12/16/19
to jenkinsc...@googlegroups.com

a b I believe the syntax you're using for the ssh URL is incorrect. Refer to the first comment in this report for a detailed description why that URL syntax is incorrect.

You are entering separating the hostname and the organization name with a ':' character. That is ambiguous in the URL specification. The text to the right of the colon could be interpreted as a service name or as a port number.

Use the scp syntax:

g...@bitbucket.org:markewaite/bin.git

Alternately, sse the ssh syntax:

mark.earl.waite@gmail.com (JIRA)

unread,
Dec 16, 2019, 4:03:03 PM12/16/19
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-26680
[~stuck_tech] I believe the syntax you're using for the ssh URL is incorrect.  Refer to the first comment in this report for a detailed description why that URL syntax is incorrect.


You are entering separating the hostname and the organization name with a ':' character.  That is ambiguous in the URL specification.  The text to the right of the colon could be interpreted as a service name or as a port number.

Use the scp syntax:

{noformat}
g...@bitbucket.org:markewaite/bin.git
{noformat}

Alternately, sse use the ssh syntax:

{noformat}
ssh://g...@gitbucket.org/markewaite/bin.git
{noformat}

mark.earl.waite@gmail.com (JIRA)

unread,
Dec 16, 2019, 4:04:03 PM12/16/19
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-26680
[~stuck_tech] I believe the syntax you're using for the ssh URL is incorrect.  Refer to the first comment in this report for a detailed description why that URL syntax is incorrect.

You are entering
separating the hostname and the organization name with a ':' character.  That is ambiguous in the URL specification.  The text to the right of the colon could be interpreted as a service name or as a port number.


Use the scp syntax:

{noformat}
g...@bitbucket.org:markewaite/bin.git
{noformat}

Alternately, use the ssh syntax:

{noformat}
ssh://g...@gitbucket.org/markewaite/bin.git
{noformat}

mark.earl.waite@gmail.com (JIRA)

unread,
Dec 16, 2019, 10:40:04 PM12/16/19
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-26680
[~stuck_tech] I believe the syntax you're using for the ssh URL is incorrect.  Refer to the first comment in this report for a detailed description why that URL syntax is incorrect.

You are separating the hostname and the organization name with a ':' character.  That is ambiguous in the URL specification for an ssh URL .  The text to the right of the colon could be interpreted as a service name or as a port number.

 Alternatives include:

Use the scp syntax:

{noformat}
g...@bitbucket.org:markewaite/bin.git
{noformat}

Alternately, use the ssh syntax:

{noformat}
ssh://g...@gitbucket.org/markewaite/bin.git
{noformat}
Reply all
Reply to author
Forward
0 new messages