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

Я пробую Hudson заменить нашу текущую настройку 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 или что-то в этом роде?


git continuous-integration jenkins hudson
person pojo    schedule 27.11.2009    source источник

Ответы (5)


arrow_upward
6
arrow_downward

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

Настройка цепочки

В конфигурации задания project_a прокрутите вниз до «Действия после сборки» и установите флажок «Сборка других проектов ...». Введите test_framework в качестве проекта для сборки.

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

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

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

person Clinton    schedule 29.11.2009
comment
1) Почему мы не можем использовать «Опрос SCM» вместе с «Построить после ..»? 2) Что, кажется, происходит с этой настройкой восходящего / нисходящего потока, репозитории git не будут в родственных каталогах. Мы попадаем в HUDSON_HOME / jobs / project_a / workspace и HUDSON_HOME / jobs / test_framework / workspace в приведенном выше примере .. Можно ли их довести до одного уровня? - person inger; 15.12.2010

arrow_upward
6
arrow_downward

Проблема с решением «Сборка других проектов» заключается в том, что при внесении изменений в 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://user@server:/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://user@server:/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 для запуска сборки.

person scribnerc    schedule 09.07.2010
comment
Будет ли это повторно клонироваться в каждой сборке? - person inger; 15.12.2010

arrow_upward
6
arrow_downward

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

Предположим, у вас есть два репозитория (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 сестрами в каталоге. Ура символические ссылки!

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

person Peter Enns    schedule 21.03.2011
comment
Спасибо, Питер. Все еще актуально! - person pojo; 11.04.2011

arrow_upward
1
arrow_downward

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

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

person Viesti    schedule 16.09.2010

arrow_upward
1
arrow_downward

Проблема, которую вы описываете, уже зарегистрирована как ошибка в багтрекере 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)
person cweiske    schedule 17.08.2011