Отримайте кілька репост із git у тій же робочій області Дженкінса

Використовуючи плагін Jenkins 1.501 та Jenkins Git 1.1.26

У мене є 3 різних git repos з декількома проектами.

Тепер мені потрібно перевірити всі проекти з 3 git repos в тій же робочій області на рабі Дженкінса. Я визначив кожне git repo в: Керування вихідним кодом: Кілька SCM . Але щоразу, коли репо перевіряється, попереднє репо (та пов'язані з ним проекти) видаляється.

Я прочитав це:

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

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

Якщо це неможливо за допомогою Дженкінса, я думаю, якийсь крок / сценарій перед складанням може бути використаний для переміщення проектів у потрібне місце. Це не можливість змінювати конфігурацію збірки проектів.

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

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

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

З плагіном декількох SCM:

• створити інший запис у сховищі для кожного сховища, яке потрібно оформити (основний проект чи проект залежності).

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

"Другого розширеного меню" вже не існує, замість цього потрібно скористатися кнопкою "Додати" (у розділі "Додаткові поведінки") та вибрати "Перейти до підкаталогу"

• якщо ви використовуєте мураш, як зараз файл build.xml з цілями збирання не в кореневому каталозі робочої області, а в підкаталозі, ви повинні відобразити це в конфігурації "Викликати мурашник". Для цього в "Invoke ant" натисніть "Advanced" і заповніть вхідний текст "Build file", включаючи ім'я підкаталогу, де знаходиться build.xml.

Сподіваюся, що це допомагає.

Оскільки плагін декількох SCM застарілий.

Завдяки Дженкінсу Трубопроводу можна замовити кілька репостів, а також побудувати його за допомогою граді

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 замість власного конвеєра, як це.

Я використовував плагін декількох SCM разом із плагіном Git успішно з Дженкінсом.

Залежно від зв’язків сховищ, інший підхід полягає в додаванні іншого сховища (сховищ) у вигляді підмодулів git до одного із сховищ. Підмодуль git створює посилання на інші репости. Ці ремоди підмодулю не клонуються, якщо ви не вказали --recursiveпрапор під час клонування "суперпроекту" (офіційний термін).

Ось команда додати підмодуль у поточний проект:

git submodule add <repository URI path to clone>

Ми використовуємо Jenkins v1.645, і git SCM нестандартно зробить рекурсивний клон для суперпроектів. Voila, ви отримуєте суперпроектні файли та всі залежні (підмодулі) repo-файли у своїх власних каталогах у тій же робочій області роботи Jenkins.

Не підтверджуючи, що це правильний підхід, скоріше це підхід.

Дженкінс: Кілька СКМ - застаріла. 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.