Использование Jenkins с настраиваемой средой сборки

Question

У нас есть собственный инструмент, который управляет несколькими компонентами по нескольким репозиториям в один проект; аналогичный по своей природе инструменту репо Google (https://code.google.com/p/git-repo/) или gitslave (http://gitslave.sourceforge.net/). Наши проекты - это не только один репозиторий git.

Зависимости определяются в репозитории "meta", который всегда проверяется первым, а затем после этого проверяются зависимости.

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

Неужели кто-нибудь это делал раньше? Я немного потерял документацию Дженкинса и не совсем уверен, с чего начать.

Answer 1

Поскольку вы хотите использовать свой инструмент, вы можете просто запустить его на первом этапе сборки (или в качестве предварительного шага для сборки maven). Как уже упоминалось в @Electrawn, вы потеряете свои номера ревизий. Тем не менее, для этого есть проблемы. Однако, если вы можете написать файл свойств с номерами ревизий, вы можете загрузить файл свойств с помощью EnvInject plugin. С этого момента у вас будет доступ к свойствам в задании построения. Вы также теряете способность Дженкинса автоматически проверять изменения. Если ваш домашний инструмент поддерживает эту функцию, вы можете создать второе задание, которое проверяет только изменения и запускает задание сборки при обнаружении изменений.

Это было всего лишь одно возможное обходное решение. С немного творчества вы можете придумать разные решения.

Лучший способ, конечно, написать собственный плагин Jenkins. Поскольку вы уже сделали большую часть работы (написание собственного инструмента), вам нужно всего лишь реализовать Jenkins API. ... или что может быть быстрее, обновите текущий плагин git, чтобы он соответствовал вашей структуре проекта.

Answer 2

Subversion (и плагин subversion для jenkins) позволяет это через SVN: Внешние легко. Личное мнение в сторону ...

Поскольку git не имеет легкой внешней функциональности, вы можете добавить несколько шагов предварительной сборки вызовов оболочки, чтобы просто проверить различные части репозитория, который вы хотите. Вы не сможете получить автоматические номера REVISION, как и другие плагины SCM.

SCM плагин, чтобы проверить главный проект

Построить задачу один (при условии, Linux):

git clone REPO %{WORKSPACE}/source/project2 

Построить задачу два:

git clone REPO %{WORKSPACE}/source/project3 

Вы можете исследовать модульности свои рабочие места и объединяя артефакты вместе в цепочку для первого комментатора, но позволяет сначала создать свой проект в одной массивной работе.