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

Использование Jenkins 1.501 и Jenkins Git plugin 1.1.26

У меня есть 3 разных репозитория git, каждый с несколькими проектами.

Теперь мне нужно проверить все проекты из трех репозиториев git в одной рабочей области на ведомом устройстве Jenkins. Я определил каждое репозиторий git в: Управление исходным кодом: несколько SCM . Но каждый раз, когда репо проверяется, предыдущее репо (и связанные с ним проекты) удаляются.

Я прочитал это:

http://jenkins.361315.n4.nabble.com/multiple-git-repos-in-one-job-td4633300.html

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

Если это просто невозможно с использованием Jenkins, я предполагаю, что для перемещения проектов в нужное место можно использовать некоторый шаг / сценарий перед сборкой. Это не вариант для изменения конфигурации сборки проектов.

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

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

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

С помощью плагина Multiple SCMs:

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

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

«Второе расширенное меню» больше не существует, вместо этого нужно использовать кнопку «Добавить» (в разделе «Дополнительные поведения») и выбрать «Проверить в подкаталог».

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

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

Поскольку подключаемый модуль Multiple 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 вместо подобного настраиваемого конвейера.

Я успешно использовал подключаемый модуль Multiple SCMs вместе с подключаемым модулем Git с Jenkins.

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

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

git submodule add <repository URI path to clone>

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

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

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

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

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

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

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
git@<host>:${REPOSITORY}
refspec: +refs/tags/${TAG}:refs/remotes/origin/tags/${TAG}
Branch Specifier: */tags/${TAG} 

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

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

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

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