Дженкинс: Получение подмодулей с помощью Git

В настоящее время я застрял в проблеме, пытаясь получить подмодули репозитория из Jenkins. Моя конфигурация прекрасна, и я могу вытащить репозитории без каких-либо подмодулей.

Я также могу вытащить основные компоненты репо с подмодулями (как с аутентификацией в имени репозитория, так и с SSH). Проблема возникает только тогда, когда мне приходится тянуть подмодульные компоненты. Я использую последнюю версию Jenkins, и я добавил часть внизу, которая предназначена для "Улучшенных подмодулей". Я выбрал "Рекурсивно обновить подмодули" здесь и выполнил сборку несколько раз безрезультатно.

Когда я пытаюсь добавить дополнительный шаг сборки внизу с командами оболочки, обновление репозиториев тоже не работает. Когда я пробую эти команды за пределами jenkins в моем терминале, это работает отлично. Вопрос, который я всегда получаю в Дженкинсе:

FATAL: Command "git submodule update" returned status code 1:

stdout: 

stderr: Cloning into 'thisismysubmodule'...
fatal: Authentication failed for 'https://git.thisismyrepo.com/scm/ap/thisismysubmodule.git/'

Я нашел эту проблему: https://issues.jenkins-ci.org/browse/JENKINS-20941, но я не могу использовать предлагаемое решение внизу из-за проблем с безопасностью. Кто-нибудь здесь имеет опыт работы с этой проблемой или возможное решение?

Ответ 1

Ниже приведено обходное решение, использующее переадресацию агента SSH. Это сработало для меня.

Сначала отредактируйте <jenkins_home>/.ssh/config и установите ForwardAgent yes
Затем установите плагин агента SSH для Jenkins.
Затем в конфигурации проекта reset учетные данные Git.
Наконец, в конфигурации проекта установите учетные данные агента SSH.

Ответ 2

Теперь для решения этой проблемы были выпущены бета-версии модулей git -client и git -plug-in. Процитировать JIRA-вопрос.

Клиентский плагин git 2.0.0-beta1 был выпущен на экспериментальный центр обновления. Он включает в себя git подмодульную аутентификацию, JGit 4.3, и требует JDK 7. Для этого требуется, по крайней мере, Jenkins 1.625 ( первая версия для мандата JDK 7)

Используя вышеизложенное, есть опция в разделе Дополнительные поведенья:

Использовать учетные данные из удаленной базы данных родительского репозитория

Это решило мою проблему при использовании Jenkins 2.11 и бета-версий подключаемого модуля под управлением Windows-сервера и ведомого. Я не проверял другие машины сборки. Также вы должны использовать один и тот же метод проверки подлинности, если используете http, вы также должны использовать это для подмодулей, если использовать SSH, вы должны использовать это для подмодулей, попытка смешивания методов будет работать неправильно.

- ОБНОВЛЕНИЕ -
Бета-версии больше не требуются, см. Следующие страницы:
Git Клиентский плагин
Git Плагин

Ответ 3

Одним из решений было бы объявить в глобальном файле конфигурации git учетную запись netrc, которая предоставила бы необходимые учетные данные для любого HTTP-запроса, поступающего из git.

git config --global credential.helper "netrc -f C:/path/to/_netrc.gpg -v"

(обязательно используйте ту же учетную запись, что и для Jenkins)

Я использую зашифрованный файл netrc, но вы можете запустить некоторый тест с помощью нешифрованного файла.

Ответ 4

Учитывая, что я попытался почти все доступные опции для получения этой работы (SSH,.netrc, hardcoded credentials,...), единственным вариантом был тот, который упоминался в нижней части проблемы JENKINS-20941 от пользователя andreg ":

Да, эта проблема для нас тоже настоящая боль. Единственный способ, который мы могли бы получить он работал для нашей установки Stash/Jenkins, чтобы создать пользователя только для чтения и жестко закодировать эти учетные данные пользователя в ссылке на подмодуль. Несмотря на плохую практику, все пользователи, работающие над репо gitуже имеют доступ как минимум для чтения, поэтому мы не чувствовали, что это слишком большая часть проблемы безопасности. например в родительском файле repo.gitmodules:

[subodule "shared-library" ] path = shared-library url = https://username:[email protected]/scm/project/shared-library.git

а затем задание Jenkins имеет "Рекурсивно обновлять подмодули".

Ответ 5

Я на самом деле просто переместил его в команду оболочки, а в командной строке я сказал, какой помощник учетных данных использовать, поскольку я на окнах, это было wincred:

git config --global credential.helper wincred
git submodule init 
git submodule sync 
git submodule update --init --recursive

Ответ 6

Это решение работало для меня:

Убедитесь, что учетные данные ssh одинаковы для родительского репо и репо-подмодуля.
Установить учетные данные для родительского репо в Jenkins. (Управление исходными кодами (выберите "Git" ) > Репозитории)
Установите файл .gitmodule, чтобы он использовал учетные данные ssh из родительского репо:
```
[submodule "foo/repository"]
   path = foo/repository
   url = ssh://[email protected]/repository
```
В этом решении есть небольшая оговорка. В любое время, когда кто-то клонирует родительское репо, им нужно будет синхронизировать URL-адрес с тем, к которому у них есть доступ. В первый раз, когда пользователь инициализирует подмодуль, им необходимо сначала отредактировать файл .gitmodules и изменить URL:
```
[submodule "foo/repository"]
   path = foo/repository
   url = ssh://[email protected]/repository
```
Затем в терминале:
```
git submodule sync
git submodule init repository
git submodule update --remote repository
```
И затем измените URL-адрес обратно на строчку сборки jenkins. Если вы не синхронизируете снова, подмодуль будет использовать URL-адрес, связанный с пользователем.

В сентябре 2016 года Дженкинс планирует выпустить новую функцию, которая позволит подмодулям делиться учетными данными родительского репозитория. Затем HTTP-url может использоваться в .gitmodule вместо ssh.

Ответ 7

Мне удалось получить эту работу, просто добавив файл .netrc с учетными данными в Linux. Не самое безопасное решение, но если вам нужно быстро его запустить, это поможет вам.