Использование Hudson и сборка шагов с несколькими Git-репозиториями - PullRequest
Новая
       25

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

16 голосов
/ 27 ноября 2009

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

Ответы [ 5 ]

6 голосов
/ 21 марта 2011

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

Предположим, у вас есть два хранилища (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) Объедините три задания в цепочку. Порядок задач извлечения может иметь или не иметь значения (вы знаете лучше, чем я), но задача без контроля версий должна быть последним звеном в цепочке.

6 голосов
/ 09 июля 2010

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

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 Хадсона для запуска сборки.

6 голосов
/ 30 ноября 2009

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

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

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

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

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

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

1 голос
/ 17 августа 2011

Проблема, которую вы описываете, уже подана как ошибка в багтрекер 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)
1 голос
/ 16 сентября 2010

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

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

...