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

Question

Я тестирую 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 или что-то в этом роде?

Answer 1

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

<Ч>

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

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

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

<Ч>

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

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

Answer 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://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

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

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

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

Answer 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 сестрами в каталоге.Ура символическим ссылкам!

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

Answer 4

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

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

Answer 5

Описываемая вами проблема уже зарегистрирована как ошибка в багтрекере Дженкинса: 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)