Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-26680

Extraneous Forward-Slash in ssh:// path to repository

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • git-plugin
    • None
    • Jenkins version 1.598; Git plugin 2.3.4

      The SO question describes my exact problem down to the log file: http://stackoverflow.com/questions/27786733/why-is-the-git-plugin-for-jenkins-rewriting-my-local-git-repo-url-with-extra-sla

      [Repost Summary]
      -----------------------
      I'm having an issue right now trying to set up a Jenkins job (on one Windows server) to monitor an internal Git repo located on a Gitosis server (on a different Windows server).

      The url looks like this: ssh://git@192.168.0.1:relative_path/repo.git (real values replaced for security, also the relative path will not work with a '~/', it only works without a leading '/').

      When running git clone from the command line with the url, everything comes out fine.

      When configuring a Git SCM in the Jenkins job it is able to run an ls-remote command (this confirms that the ssh keys are properly configured for the Jenkins instance).

      However when the job executes, the url appears to be rewritten with an additional forward slash which causes the clone command to fail.

      Started by user Meh
      [EnvInject] - Loading node environment variables.
      Building in workspace D:\local_repo_test
      > git.exe rev-parse --is-inside-work-tree # timeout=10
      Fetching changes from the remote Git repository
      > git.exe config remote.origin.url ssh:///git@192.168.0.1:relative_path/repo.git # timeout=10
      Fetching upstream changes from ssh:///git@192.168.0.1:relative_path/repo.git
      > git.exe --version # timeout=10
      > git.exe -c core.askpass=true fetch --tags --progress ssh:///git@192.168.0.1:relative_path/repo.git +refs/heads/:refs/remotes/origin/
      ERROR: Error fetching remote repo 'origin'
      ERROR: Error fetching remote repo 'origin'
      Finished: FAILURE
      It's the '///' that bothers me. Has anyone seen anything like this?

      Any help on this would be appreciated.

          [JENKINS-26680] Extraneous Forward-Slash in ssh:// path to repository

          Bryan Garretson created issue -

          Mark Waite added a comment - - edited

          I suspect there is something in the plugin which is attempting to rewrite the URL and is adding the extra slash.

          I think the syntax ssh://user@hostname:relative_path/repo.git is ambiguous, though you say that it seems to be understood by git.

          I use ssh://user@hostname:port_number/absolute_path/repo.git to allow my Jenkins job ssh access through port_number to a git repository on hostname at /absolute_path/repo.git. On my computer named "wheezy64b", I specify the URL as ssh://mwaite@wheezy64b:45022/var/lib/git/mwaite/jenkins/git-client-plugin.git

          I can use ssh://user@hostname:ssh/absolute_path/repo.git to allow my Jenkins job ssh access through the ssh port to a git repository on hostnanme at /absolute_path/repo.git. On my computer named "mark-pc1", I specify the URL as ssh://mwaite@mark-pc1:ssh/var/lib/git/mwaite/jenkins/git-client-plugin.git

          I'm impressed that the git command recognizes the relative path, since it seems like my second syntax (using the word "ssh" for the ssh port number) creates a conflicting case with your relative path case. I've been unable to make a relative path work with ssh:// syntax and the git plugin. Can you provide more details on the syntax you use which works?

          I agree that this is a bug in the git plugin or the git client plugin, though considering the ambiguity in the ssh URL syntax, I don't think I will ever work on fixing that bug. The fix would need to identify those cases where the plugin rewrites the URL and intentionally decide not to rewrite the URL, at least for this case.

          Mark Waite added a comment - - edited I suspect there is something in the plugin which is attempting to rewrite the URL and is adding the extra slash. I think the syntax ssh://user@hostname:relative_path/repo.git is ambiguous, though you say that it seems to be understood by git. I use ssh://user@hostname:port_number/absolute_path/repo.git to allow my Jenkins job ssh access through port_number to a git repository on hostname at /absolute_path/repo.git. On my computer named "wheezy64b", I specify the URL as ssh://mwaite@wheezy64b:45022/var/lib/git/mwaite/jenkins/git-client-plugin.git I can use ssh://user@hostname:ssh/absolute_path/repo.git to allow my Jenkins job ssh access through the ssh port to a git repository on hostnanme at /absolute_path/repo.git. On my computer named "mark-pc1", I specify the URL as ssh://mwaite@mark-pc1:ssh/var/lib/git/mwaite/jenkins/git-client-plugin.git I'm impressed that the git command recognizes the relative path, since it seems like my second syntax (using the word "ssh" for the ssh port number) creates a conflicting case with your relative path case. I've been unable to make a relative path work with ssh:// syntax and the git plugin. Can you provide more details on the syntax you use which works? I agree that this is a bug in the git plugin or the git client plugin, though considering the ambiguity in the ssh URL syntax, I don't think I will ever work on fixing that bug. The fix would need to identify those cases where the plugin rewrites the URL and intentionally decide not to rewrite the URL, at least for this case.

          Mark Waite added a comment - - edited

          I performed some further tests with multiple versions of git. I can't find a way to make any of them work with a relative path in an ssh URL. The tests used git / operating system versions:

          • git 1.7.1, CentOS 6.6, "git clone ssh://mwaite@mark-pc1:bin/" fails and reports "ssh: Could not resolve hostname mark-pc1:bin: Name or service not known"
          • git 1.7.2.5, Debian 6, "git clone ssh://mwaite@mark-pc1:bin/" fails and reports "ssh: Could not resolve hostname mark-pc1:bin: Name or service not known"
          • git 1.7.10.4, Debian 7, "git clone ssh://mwaite@mark-pc1:bin/" fails and reports "ssh: Could not resolve hostname mark-pc1:bin: Name or service not known"
          • git 2.1.4, Debian Testing, "git clone ssh://mwaite@mark-pc1:bin/" fails and reports "fatal: '/' does not appear to be a git repository"
          • git 2.2.1, Ubuntu 14.04, "git clone ssh://mwaite@mark-pc1:bin/" fails and reports "fatal: '/' does not appear to be a git repository"

          What git version are you running which passed that test? Are you using command line git or JGit?

          Later investigations in JENKINS-27483 showed that msysgit on Windows allows that syntax. It seems to be the only platform which allows it.

          I agree that this is a bug (the plugin should not rewrite the ssh URL), but even if that bug is fixed, the URL syntax being used is not platform portable. It only works on msysgit on Windows.

          Mark Waite added a comment - - edited I performed some further tests with multiple versions of git. I can't find a way to make any of them work with a relative path in an ssh URL. The tests used git / operating system versions: git 1.7.1, CentOS 6.6, "git clone ssh://mwaite@mark-pc1:bin/" fails and reports "ssh: Could not resolve hostname mark-pc1:bin: Name or service not known" git 1.7.2.5, Debian 6, "git clone ssh://mwaite@mark-pc1:bin/" fails and reports "ssh: Could not resolve hostname mark-pc1:bin: Name or service not known" git 1.7.10.4, Debian 7, "git clone ssh://mwaite@mark-pc1:bin/" fails and reports "ssh: Could not resolve hostname mark-pc1:bin: Name or service not known" git 2.1.4, Debian Testing, "git clone ssh://mwaite@mark-pc1:bin/" fails and reports "fatal: '/' does not appear to be a git repository" git 2.2.1, Ubuntu 14.04, "git clone ssh://mwaite@mark-pc1:bin/" fails and reports "fatal: '/' does not appear to be a git repository" What git version are you running which passed that test? Are you using command line git or JGit? Later investigations in JENKINS-27483 showed that msysgit on Windows allows that syntax. It seems to be the only platform which allows it. I agree that this is a bug (the plugin should not rewrite the ssh URL), but even if that bug is fixed, the URL syntax being used is not platform portable. It only works on msysgit on Windows.
          Mark Waite made changes -
          Link New: This issue is duplicated by JENKINS-27483 [ JENKINS-27483 ]

          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.

          Jerome Oufella added a comment - 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.

          Mark Waite added a comment -

          jero 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?

          Mark Waite added a comment - jero 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 added a comment - - edited

          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:

          ...
          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.
          ...
          

          EDIT: fix code block

          Jerome Oufella added a comment - - edited 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: ... 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. ... EDIT: fix code block

          Note, this was tested with the following configuration:

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

          Jerome Oufella added a comment - Note, this was tested with the following configuration: Jenkins 1.643 Git plugin 2.4.1 Git client plugin 1.19.1

          Mark Waite added a comment -

          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 Waite added a comment - 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.
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 160755 ] New: JNJira + In-Review [ 180475 ]

            Unassigned Unassigned
            nhvirtuoso Bryan Garretson
            Votes:
            2 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: