Почему плагин Git для Jenkins переписывает мой локальный URL-адрес git-репо с дополнительными косыми чертами?

Question

У меня сейчас проблема с попыткой настроить задание Jenkins (на одном сервере Windows) для мониторинга внутреннего репозитория Git, расположенного на сервере Gitosis (на другом сервере Windows).

URL выглядит следующим образом: ssh: //git@192.168.0.1:lative_path / repo.git (реальные значения заменены для безопасности, также относительный путь не будет работать с "~/", он работает только без начального "/" ").

При запуске git clone из командной строки с URL, все получается нормально.

При настройке Git SCM в задании Jenkins он может выполнить команду ls-remote (это подтверждает, что ключи ssh правильно настроены для экземпляра Jenkins).

Однако, когда задание выполняется, URL, кажется, переписывается с дополнительной косой чертой, которая приводит к сбою команды клонирования.

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

Меня беспокоит "///". Кто-нибудь видел что-нибудь подобное?

Любая помощь в этом будет оценена.

Answer 1

Насколько я могу судить по проверке различных версий git, синтаксис относительного пути, который вы используете в протоколе ssh, неоднозначен. Это интерпретируется, как вы надеетесь в версиях msysgit для Windows, но не на любой другой платформе, которую я тестировал.

Когда я тестировал

• git 1.7.1, CentOS 6.6, git clone ssh://mwaite@mark-pc1:bin/ неудачи и отчеты 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/ неудачи и отчеты 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/ неудачи и отчеты ssh: Could not resolve hostname mark-pc1:bin: Name or service not known
• git 2.1.4, Тестирование Debian, git clone ssh://mwaite@mark-pc1:bin/ неудачи и отчеты fatal: '/' does not appear to be a git repository
• Git 2.2.1, Ubuntu 14.04, git clone ssh://mwaite@mark-pc1:bin/ завершается неудачно и выдает сообщение "fatal: '/' не является git-репозиторием"
• Git 2.3.0, Ubuntu 14.04, git clone ssh://mwaite@mark-pc1:ssh/home/mwaite/bin успешно и клонирует репо из /home/mwaite/bin, используя протокол ssh

Насколько я могу судить, если первое слово после двоеточия - это протокол (например, ssh) или номер порта (например, 22), то это интерпретируется как номер службы или порта, который будет использоваться для доступа к хранилищу.

Я также описал некоторые из этих деталей в JENKINS-26680 и JENKINS-27483

Answer 2

Поскольку я не мог привлечь внимание людей из Дженкинса к попыткам выяснить, почему URL переписывается с помощью ///, и я также не мог определить, было ли что-то не так с Gitosis, я нашел обходной путь.

Поскольку Cygwin, SSH и Gitosis уже были установлены и запущены, я решил добавить нового пользователя на компьютер и запустить через него всю команду git ssh.

Выполните следующие действия, чтобы добавить нового пользователя http://techtorials.me/cygwin/create-and-add-users/

Затем я chmod'ed и chgrp'ed / home / git / reposotories для группы sshUsers. Как только это было сделано, я смог использовать URL-адрес Git SSH с абсолютным именем пути, минуя проблему URL /// с jenkins.

Answer 3

У меня возникла та же проблема с использованием Jenkins в сочетании с частным хранилищем битовых корзин, которое я хотел клонировать через ssh. Как уже упоминалось в ответе Марка Уэйта, некоторые признают это ошибкой. Однако есть другие, которые думают, что это ожидаемое поведение, потому что "относительные URI" не поддерживаются JENKINS -26327.

Временным обходным решением, которое сработало в моем случае, было добавление порта № 22. Поэтому в конвейере Jenkins я заменил

url: 'ssh://[e-mail]:/my_team/my_repo.git'

с

url: 'ssh://[e-mail]:22/my_team/my_repo.git'

И теперь трубопровод работает как положено.

Answer 4

Это длинный пример, но просто для проверки - возможно, вы используете параметры в пути? Что-то вроде $PROTOCOL/$URL/$PATH с PROTOCOL='ssh://'? Звучит надуманно, так что обид не имел в виду. Но однажды я сделал нечто подобное, и параметризация помешала мне увидеть, что поле на самом деле посылает на одну косую черту больше, чем следовало бы.

Answer 5

Это сработало для меня.

ssh://awc@192.168.1.32:22/home/awc/GIT_HOME/awc.git

т.е. добавив дополнительный номер порта 22 (порт SSH) после IP-адреса

Answer 6

При использовании URL-адреса Git SSH с префиксом ssh://, замените двоеточие перед названием организации на косую черту:

git clone ssh://git@192.168.0.1/relative_path/repo.git

Или просто используйте URL как есть без префикса ssh://:

git clone git@192.168.0.1:relative_path/repo.git