Jenkins Ошибка клонирования удаленного репо 'origin', slave node

Мне нужна помощь здесь. Это была неделя, с которой я столкнулся с этой проблемой, не могу понять, что происходит. Я не могу клонировать репо git из подчиненного node (Jenkins). Я добавил ключ ssh, host и slave (я уже пробовал генерировать один ключ и один для каждого виртуального и хоста)).

В Дженкинсе:

url: git @github.com: < репо >
Учетные данные: здесь я попытался с именем пользователя/паролем, именем пользователя с ssh файлом, именем пользователя с ключом ssh напрямую и -none -.

Не похоже, что есть проблема аутентификации, так как я могу клонировать репо вручную с консоли (как с ведомым, так и с хостом). Я также могу подключиться к

ssh -T git @github.com

поэтому ssh-ключ в порядке, но когда я его создаю, это появляется на консоли:

Создание удаленно на IE10Win7 в рабочем пространстве C:\Users\IEUser\Desktop\< папкa >

Сначала вытрите рабочую область.

Клонирование удаленного хранилища git

Репозиторий клонирования git @github.com: < репо > .git

git init C:\Users\IEUser\Desktop\< папкa > # timeout = 10

ОШИБКА: Ошибка клонирования удаленного репо 'origin'

ОШИБКА: Ошибка клонирования удаленного репо 'origin'

Выполнение задачи сборки Post...

Есть ли у кого-нибудь идеи? Надеюсь, кто-то может дать мне ключ, спасибо!

Ответ 1

Я исправил эту проблему, установив ведомый node путь инструмента, выбрав git и установив его значение

C:\Program Files (x86)\Git\bin\git.exe

Местоположение: Настроить node - Местоположение инструмента

Ответ 2

Недавно я обновил несколько плагинов jenkins и имел эту проблему после обновлений. Откат плагина git не помог, но я сделал несколько других вещей, чтобы заставить его работать. Я перечислил все три здесь, но, вероятно, (2) это устранило проблему. По-видимому, исполняемый файл git был сброшен до значения по умолчанию. Таким образом, настройка исполняемого файла git в рамках конкретного проекта была, вероятно, всем, что было необходимо. Однако другие предметы также могут пригодиться.

(1) По умолчанию git на jenkins linux install geenrally указывает на /usr/lib... Вам нужно указать отдельную GitForWindows, которая указывает на версию Windows:

Manage Jenkins
Configure System
Under Git - Git Installations
    Add Git -> Git
    Give it a name to be referenced in projects
      (mine is WindowsGit)
    Set Path to Git Executable
      (mine is "C:\Program Files (x86)\Git\bin\git.exe")
      (for recent git the path is "C:\Program Files\Git\bin\git.exe")

(2) Настройте git на конкретный проект:

Select the project
Select Configure
Under Source Code Management - Git
    Select Git Executable as configured in 1)
    Set credentials or add new (ssh keys, etc)

(3) Обновление службы ведомого устройства jenkins для запуска в качестве конкретного пользователя:

Go to Windows Services on the slave -- StartMenu, type "services"
Select the Jenkins Slave service in the list on the right
Right-click and select "Properties" of the Jenkins Slave service
Select the "Log On" tab
Update the username and password used in manual tests
    Domain login can be specificied with <DOMAIN>\<USERNAME>
    Local logins just use <USERNAME>
OK to save and exit
Right-click again and select "Restart" to make the changes active.

Ответ 3

В моем случае я нашел подходящее обходное решение. Команда git clone всегда наследует владельца процесса, что может иметь значение, даже если оба владельца Jenkins (SYSTEM) и cmd (USER), похоже, имеют одинаковые права в вашей системе. Все остальные конфигурации были идентичны (ключи, известные хосты, Git клиентская версия).

Итак, насколько я могу судить, вызов git clone из cmd будет успешным, потому что он вызывает пульт как USER, тогда как git clone, вызываемый из Jenkins, может быть отклонен, потому что он вызывает пульт как SYSTEM. В службах, где вы обычно запускаете Jenkins через графический интерфейс пользователя, вы можете настроить службу для запуска как другой пользователь (щелкните правой кнопкой мыши по сервису → Свойства → Вход в систему). Мне пришлось поместить его как USER @DOMAIN, например. [email protected] или около того. Я не уверен, как будет выглядеть cmd-параметр, но я бы ожидал, что он будет таким.

Кроме того, я не совсем понимаю, какая разница в этом обходном пути делает в конце, потому что на моих Jenkins система и пользователь настроены на то, чтобы иметь одинаковые права в системе, и они, конечно, оба признаны как "Дженкинс" дистанционный пульт. Тем не менее, это делает трюк для меня. Более глубокие идеи приветствуются.

Ответ 4

Я столкнулся с подобной проблемой и обнаружил, что мне нужно добавить git в свою переменную среды PATH для ведомого на базе Windows. Я думаю, что предложение @dhj 2 может работать и в этом случае.

Я нашел это обходное решение Дженкинс Джира.

Ответ 5

В моем случае я начал получать эту точную ошибку после обновления Git на некоторых моих машинах сборки (через Chocolatey, используя пакет "git.install" ) с 1.9.4 до 2.5.0. Старая версия 1.9.4 была 32-разрядной, но новая была 64-разрядной, поэтому место установки по умолчанию переключилось с C:\Program Files (x86)\Git на C:\Program Files\Git. У меня был 64-битный путь, сконфигурированный на главном сервере Jenkins (поскольку у него была новая версия Git), но некоторые подчиненные устройства по-прежнему имели более старую 32-разрядную версию, поэтому ведомые устройства пытались использовать неправильный путь. Я мог бы переопределить путь Git для отдельных ведомых устройств, но для меня было проще обновить все подчиненные устройства до новой 64-разрядной версии.

Ответ 6

Я пробовал больше всего:

Укажите расположение git. Установите пользователя службы. Запуск от имени администратора.

Ничего из этого не получилось. В конце концов решили удалить git64 и установить git32... изменили путь git к новому местоположению (в файлах программ x86). И все сработало.

Ответ 7

Недавно я столкнулся с этой проблемой.

У нас были некоторые элементы нашего PATH EV, которые мы добавили при попытке подключить Winium и Selenium к нашему экземпляру Jenkins.

Мы удалили эти предметы, но Дженкинс, похоже, держался за ценности. После небольшого поиска неисправностей: перезапуск Jenkins; перезапуск сервера Jenkins; установка EV на уровне node; и т.д. мы перезапустили JNLP-службу Jenkins на ведомом Windows.

И они жили долго и счастливо.