Использование Hudson и шаги сборки с несколькими хранилищами git

Я пытаюсь Хадсона заменить нашу текущую настройку Buildbot. Я установил плагин git. Наша текущая настройка похожа:

ssh://server:/repo/test_framework.git
ssh://server:/repo/project_a.git

Теперь, чтобы построить project_a, я добавил новое задание с несколькими репозиториями git (те, что указаны выше). Я хотел, чтобы Хадсон клонировал репозитории в разные каталоги под $WORKSPACE, потому что test_framework нуждается в этой иерархии. Но Хадсон, кажется, объединяет все в $WORKSPACE. Из журнала консоли:

warning: no common commits
...
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 96d2b3c27595de243702414c4358366923696d78
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 5bb011b3fa288afd5e4392640b32b8bcc982103e
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 aa6ade81669883909ba5f5459a205df1bd0df3c0

Могу ли я настроить это в Hudson, чтобы лучше соответствовать нашей настройке проекта? Нужно ли создавать локальный фиктивный репозиторий git с каждым проектом в качестве подмодулей git или что-то еще?

Ответ 1

Внутри Hudson вы можете объединить несколько заданий вместе. Вы можете попробовать создать отдельные задания Hudson для test_framework и другое для project_a. Хадсон создает отдельный каталог в $WORKSPACE для каждого задания, поэтому теперь у вас должно быть два разных каталога в $WORKSPACE.

Цепочка настройки

В конфигурации задания project_a прокрутите вниз до действий Post-build и проверьте Build other projects... Введите в test_framework как проект для сборки.

В конфигурации задания test_framework убедитесь, что Poll SCM не отмечен, а Build после того, как другие проекты установлены в project_a.

Как это работает

Теперь вы сконфигурировали project_a, чтобы опросить SCM, ища изменения, когда обнаружены изменения, они вытащит их из git. Запустите шаги сборки (если есть) и завершите запуск задания test_framework, чтобы вытащить изменения из git (если есть) и выполнить его шаги сборки.

Ответ 2

Проблема с решением "Построить другие проекты" заключается в том, что если есть изменения в test_framework, это не приведет к созданию project_a. Вместо этого я рекомендую отказаться от плагина git и настроить шаг сборки "Выполнение оболочки" со следующим:

rm -rf ${WORKSPACE}/*

git clone ssh://server:/repo/test_framework.git ${WORKSPACE}/test_framework
cd ${WORKSPACE}/test_framework
git fetch -t ssh://[email protected]:/repo/test_framework.git +refs/heads/*:refs/remotes/origin/*
git ls-tree HEAD

git clone ssh://server:/repo/project_a.git ${WORKSPACE}/project_a
cd ${WORKSPACE}/project_a
git fetch -t ssh://[email protected]:/repo/project_a.git +refs/heads/*:refs/remotes/origin/*
git ls-tree HEAD

Затем создайте файлы крюка "server:/repo/test_framework.git/hooks/post-receive" и "server:/repo/project_a.git/hooks/post-receive" со следующим содержимым:

#!/bin/sh
curl http://hudson/job/job_name/build

Теперь, всякий раз, когда изменения переносятся в любой репозиторий, хук будет использовать API Hudson для запуска сборки.

Ответ 3

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

Предположим, у вас есть два репозитория (A и B).

Шаги:

1) Сделайте два проекта для вывода кода из удаленных репозиториев A и B. Поместите любые необходимые шаги сборки в любой репозиторий.

2) Создайте третий каталог без управления исходным кодом. Добавьте в этот проект шаг сборки, чтобы выполнить команду оболочки, похожую на это:

ln -s /var/lib/jenkins/jobs/A/workspace A
ln -s /var/lib/jenkins/jobs/B/workspace B

(Ваши пути могут быть не такими же. Посмотрите сами!)

Теперь вы можете добавить любые другие шаги сборки, которые зависят от A и B, являющихся сестрами в каталоге. Yay символические ссылки!

3) Соедините три задачи вместе. Порядок задач потянуть может быть или не иметь значения (вы знаете лучше, чем я), но задача без контроля источника должна быть последним звеном в цепочке.

Ответ 4

Я столкнулся с той же проблемой и в настоящее время решил ее, создав работу для каждого проекта и используя Copy Artifact Plugin, чтобы создать зависимым от работы, даже если в нем выполняется обновление Git (это делается для того, чтобы избежать создания посередине обновления проекта, на который мы зависим).

Итак, project_a скопирует последние стабильные артефакты, которые ему нужны из test_framework, и обновление для тестовой среды вызовет сборку в project_a. project_a все равно может быть вызван изменением в Git, он просто снова копирует последние артефакты в test_framework.

Ответ 5

Проблема, которую вы описываете, уже подана как ошибка в багтрекере Jenkins: https://issues.jenkins-ci.org/browse/JENKINS-8082

Мы используем опцию "настраиваемое рабочее пространство" в расширенной конфигурации задания проекта, чтобы проверить наш репозиторий заданий в подкаталоге другого задания.

Эта другая работа проверяет главный каталог со всеми подмодулями:

var/lib/jenkins/jobs/
  + main_job
    + workspace (main git checkout with submodules)
      + modules
        + mod1
        + mod2
  + mod1_job (custom workspace set to main_job/workspace/modules/mod1)
    + workspace (empty)