Дженкинс: Как собрать несколько проектов верхнего уровня из репозитория git?

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

Идентификатор, вероятно, идет с вариантом 1. Дисковое пространство обычно дешевое.

Но 3 облегчит развертывание в новых системахбез настройки Дженкинс снова.