Оформление нескольких репозиториев git в одном рабочем пространстве Jenkins

Ответ 1

Проверять более одного репо за раз в одном рабочем пространстве невозможно с помощью Jenkins + Git Plugin.

В качестве обходного пути, вы можете либо иметь несколько вышестоящих заданий, каждое из которых извлекает по одному репо, а затем копировать в конечную рабочую область проекта (проблематично на нескольких уровнях), либо вы можете настроить шаг сценариев оболочки, который проверяет каждый необходимый репо в рабочее пространство во время сборки.

Раньше плагин Multiple SCM мог помочь с этой проблемой, но теперь он устарел. Со страницы плагина Multiple SCM: "Пользователи должны перейти на https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin. Pipeline предлагает лучший способ проверки нескольких SCM и поддерживается основной группой разработчиков Jenkins".

Ответ 2

С плагином нескольких SCM:

• создать другую запись в репозитории для каждого репозитория, который вам нужен для проверки (основной проект или проект зависимости.

• для каждого проекта, в "расширенном" меню (второе "расширенное" меню есть две кнопки с надписью "advanced" для каждого репозитория), найдите текстовое поле "Local subdirectory for repo (optional)". Вы можете указать там подкаталог в каталоге "рабочая область", куда вы хотите скопировать проект. Вы можете сопоставить файловую систему моего компьютера разработки.

"Второе расширенное меню" больше не существует, вместо этого нужно использовать кнопку "Добавить" (в разделе "Дополнительные действия" ) и выбрать "Отъезд в подкаталог"

• если вы используете ant, так как теперь файл build.xml с целями сборки не находится в корневом каталоге рабочей области, а в подкаталоге, вы должны отразить это в конфигурации "Invoke Ant", Для этого в "Invoke Ant" нажмите "Дополнительно" и введите текст ввода "Создать файл", включая имя подкаталога, в котором находится файл build.xml.

Надеюсь, что это поможет.

Ответ 3

Поскольку плагин для нескольких SCM устарел.

С помощью Jenkins Pipeline можно оформить несколько репозиториев git, а после сборки использовать gradle

node {   
def gradleHome

stage('Prepare/Checkout') { // for display purposes
    git branch: 'develop', url: 'https://github.com/WtfJoke/Any.git'

    dir('a-child-repo') {
       git branch: 'develop', url: 'https://github.com/WtfJoke/AnyChild.git'
    }

    env.JAVA_HOME="${tool 'JDK8'}"
    env.PATH="${env.JAVA_HOME}/bin:${env.PATH}" // set java home in jdk environment
    gradleHome = tool '3.4.1' 
}

stage('Build') {
  // Run the gradle build
  if (isUnix()) {
     sh "'${gradleHome}/bin/gradle' clean build"
  } else {
     bat(/"${gradleHome}\bin\gradle" clean build/)
  }
}
}

Возможно, вы захотите использовать подмодули git вместо собственного конвейера, подобного этому.

Ответ 4

Я использовал несколько плагинов SCM в сочетании с плагином Git с Jenkins.

Ответ 5

В зависимости от отношений репозиториев, другой подход заключается в добавлении другого репозитория (репозиториев) в виде подмодулей git в один из репозиториев. Подмодуль git создает ссылку на другие репозитории. Эти репозитории субмодулей не клонируются, если вы не укажете флаг --recursive при клонировании "суперпроекта" (официальный термин).

Вот команда для добавления подмодуля в текущий проект:

git submodule add <repository URI path to clone>

Мы используем Jenkins v1.645, и git SCM из коробки сделает рекурсивный клон для суперпроектов. Вуаля, вы получаете файлы суперпроекта и все зависимые (подмодульные) файлы репо в их соответствующих каталогах в той же рабочей области Jenkins.

Не утверждая, что это правильный подход, а скорее подход.

Ответ 6

Дженкинс: несколько SCM - не рекомендуется. GIT Plugin - не работает для нескольких репо.

Скриптинг/конвейер как код - это путь.

Ответ 7

У меня тоже была эта проблема. Я решил это, используя Trigger/call builds на других проектах. Для каждого репозитория я вызываю нижестоящий проект, используя параметры.

Основной проект:

This project is parameterized
String Parameters: PREFIX, MARKETNAME, BRANCH, TAG
Use Custom workspace: ${PREFIX}/${MARKETNAME}
Source code management: None

Затем для каждого репозитория я вызываю следующий проект:

Trigger/call builds on other projects: 
Projects to build: Linux-Tag-Checkout
Current Build Parameters
Predefined Parameters: REPOSITORY=<name>

Нижестоящий проект: Linux-Tag-Checkout:

This project is parameterized
String Parameters: PREFIX, MARKETNAME, REPOSITORY, BRANCH, TAG
Use Custom workspace:${PREFIX}/${MARKETNAME}/${REPOSITORY}-${BRANCH}
Source code management: Git
[email protected]<host>:${REPOSITORY}
refspec: +refs/tags/${TAG}:refs/remotes/origin/tags/${TAG}
Branch Specifier: */tags/${TAG} 

Ответ 8

Мы используем git-repo для управления нашими несколькими репозиториями GIT. Существует также Jenkins Repo plugin, который позволяет проверять все или часть репозиториев, управляемых git -repo, на одно рабочее пространство Jenkins.

Ответ 9

У меня похожая проблема. Я хочу, чтобы содержимое двух репозиториев находилось в одной рабочей области (то есть в одной папке на хосте jenkins).

Dockerfile (как и Jenkinsfile) включен в Repo1, но для него нужны файлы (из-за команды ADD) из Repo2. Моя идея состояла в том, чтобы подготовить рабочее пространство до запуска контейнера Docker, например, клонировать Repo2 на этапе, который определен до начала реального действия. Но похоже, что Jenkins создает собственный каталог для каждого этапа, поэтому файлы Repo2 находятся в другой папке, чем Dockerfile из Repo1, что означает, что файлы нельзя добавить в контейнер Docker.

Любая идея?

Заранее спасибо.

Ответ 10

Проверять более одного репо за раз в одном рабочем пространстве можно с помощью плагина Jenkins + Git (возможно, только в более поздних версиях?).

В разделе "Управление исходным кодом" не выбирайте "Git", а "Несколько SCM" и добавьте несколько репозиториев Git.

Убедитесь, что во всех, кроме одного, вы добавили в качестве "Дополнительного поведения" действие "Извлечь в подкаталог" и укажите отдельный подкаталог.