Jenkins: Как создать несколько проектов верхнего уровня из хранилища git?

У меня есть репозиторий Git, который содержит кучу проектов maven верхнего уровня (каждый из них находится в своем подкаталоге с pom.xml). Верхний уровень означает, что эти проекты находятся в подкаталоге непосредственно под корнем репозитория. Все эти проекты должны оставаться в том же хранилище Git.

repo
+--- projectA
    +--- pom.xml

+--- projectB
    +--- pom.xml

Они могут/должны быть созданы независимыми заданиями jenkins. Таким образом, у нас есть работа для projectA и одна для projectB.

Раньше с Subversion мне удалось настроить задание Jenkins (для каждого проекта), которое проверит только источник проекта и запустит сборку Maven из pom.xml.

При модели Git (вероятно, такой же со всеми DVCS) это изменяется, и я не уверен, что лучше всего подходит. Есть несколько вариантов, которые я вижу и от которых мне не нравится:

Каждое задание Дженкинса настроено для клонирования/вытягивания полного репозитория Git и относится к /pom.xml для сборки Maven. Таким образом, работа имеет весь код, но строит только его кусочек.
Git предлагает субмодули (http://book.git-scm.com/5_submodules.html), которые кажутся быть немного сложным для обработки (и может легко сломаться)
Создайте проект maven parent (агрегатор, содержащий все проекты), который запускает каждый проект (имея одно задание jenkins). Этот pom.xml содержит элементы для projectA и projectB.

Вы видите более полезный подход для этого (очень типичная настройка). Каков ваш опыт? Любые лучшие практики?

Ответ 1

Я думаю, вы работаете против зерна здесь. Если эти проекты будут выпущены как версия, вы должны создать родительский POM. Но у вас должно быть только одно задание CI. Если вы хотите, чтобы эта сборка выполнялась быстро, вы можете настроить ее только для создания модулей, которые были изменены с момента последней сборки (расширенная кнопка в разделе "Сборка" - "Инкрементная сборка - только сборка измененных модулей" ). Вы также можете сказать Дженкинсу "Выполнять параллельные сборки, если необходимо", чтобы сразу проверить несколько коммитов.

Но мне интересно, почему вы думаете, что хотите работать с несколькими CI? Если вы понимаете, что эти два проекта имеют разные жизненные циклы, возможно, они должны быть версиями отдельно и поэтому должны находиться в отдельных хранилищах git. Не сохраняйте репозитории git, они дешевы. На самом деле, чем больше веселее почти в каждом случае.

Обычно вы хотите, чтобы данный pom создал один артефакт. Агрегаторные помпы полезны для разбивания частей более крупного артефакта на подмодули, но только если эти подмодули не выпускаются сами по себе.

Ответ 2

@recampbell, у меня та же проблема. У нас есть несколько взаимосвязанных проектов в одном репозитории Hg.

Таким образом мы точно знаем, под какой версией (номер версии hg), каждый другой компилируется. Когда я говорю точно, я имею в виду, что могу проверить, что он идентичен двоичным.

Использование номеров релизов слишком грубо. Например, сегодня я нашел ошибку, которая была воспроизводима только под hg-версией 3367, но не в версии hg 3368. Использование нескольких hg-репозиций, которые были бы невоспроизводимыми, поскольку каждый проект каждый день имеет несколько коммитов, и поэтому он невозможно точно определить, какая версия каждого отдельного проекта была использована, только версия hg является правильной для использования (используя bisect для поиска ошибки).

Оказалось, что мы изменили версию драйвера клиентской базы данных в одном из подпроектов, и это привело к автоматическому сбою dao-генерации с NPE. Драйвер, конечно, если версия выпуска, которую мы не пишем, мы просто используем тот, который предоставляется поставщиком. Это потребовало бы от нас нескольких дней отладки, но, поскольку мы используем Jenkins для сборки каждый час, мы знали, что для поиска было от 10 до 20 коммитов, и только 3 или 4 касались дао-генератора, поэтому это была легкая задача.

Смешанные версии каждого проекта были бы болью в нижней задней части спины, так как у нас было бы несколько различных dao-generator-3.1.2.jar, которые были бы немного отличающимися друг от друга (если вы не ожидаете нам изменить номера версий после каждого фиксации или если в Jenkins/maven есть какая-то конфигурация, что бы это сделать автоматически? Это было бы здорово...).

Ответ 3

Хорошо, что лучше не повторять себя. Таким образом, наличие супер POM было бы хорошим с этой точки зрения.

Id, вероятно, идет с опцией 1. Дисковое пространство обычно дешево.

Но 3 упростит развертывание в новых системах, не создавая снова Jenkins.