Я пытаюсь настроить наш процесс сборки в hudson.
Работа 1 будет очень быстрой (надеюсь) непрерывной работой по сборке интеграции, которая будет построена часто.
Задание 2 будет отвечать за запуск комплексного набора тестов с регулярным интервалом или вручную.
Задание 3 будет отвечать за запуск инструментов анализа в кодовой базе (как Job 2).
Я попытался использовать функцию "Расширенные проекты > использовать пользовательскую рабочую область", чтобы код, скомпилированный в Job 1, можно было использовать в Job 2 и 3. Однако кажется, что все артефакты сборки остаются внутри рабочего пространства Job 1. Я делаю это правильно? Есть ли лучший способ сделать это? Наверное, я ищу что-то похожее на установку конвейера сборки... так что все может быть общим, и соответствующие задания могут выполняться поэтапно.
(Я также рассматривал использование "пакетных задач"... но похоже, что они не могут быть запланированы? только запускаются вручную?)
Любые предложения приветствуются. Спасибо!
Возможно, вы захотите попробовать плагин Copy Artifact:
http://wiki.hudson-ci.org/display/HUDSON/Copy+Artifact+Plugin
Ваша непрерывная работа может собрать необходимые артефакты, а ваши другие две работы могут привлечь их для проведения анализа.
У Hudson есть плагин для этой проблемы: http://wiki.hudson-ci.org/display/HUDSON/Clone+Workspace+SCM+Plugin (ссылка в настоящее время не работает)
Соответствующая страница Jenkins находится здесь: https://wiki.jenkins-ci.org/display/JENKINS/Clone+Workspace+SCM+Plugin
Да, эта страница вики была не очень полезной, поскольку она пытается сделать ее очень элегантной. Правда в том, что Хадсон не поддерживает работу цепочки очень элегантно, но если вам нужно передать материал с одной работы на другую.
Я также выполняю метод zip-up-and-copy-workspace для переноса рабочих областей с одного задания на другое. У меня есть быстрая сборка, сборка полного анализа, а затем сборка дистрибутива. Между ними я использую Ant для создания временных меток и "штампов", чтобы отметить, какой номер задания создал другой номер задания. Функция отпечатка пальца помогает отслеживать файлы, но поскольку я не собираюсь архивировать zip файлы рабочего пространства, отпечатки пальцев бесполезны для пользователей, потому что они не могут фактически видеть рабочие пространства.
Вы посмотрели на Hudson wiki? В частности: Разделение большой работы на более мелкие задания
У меня была одна и та же проблема, и в итоге я столкнулся с отдельными проектами для долговременных задач. Первым шагом в этих проектах было копирование всех файлов из рабочей области Job 1 (то есть последняя сборка) в рабочие области Job 2/3/etc. Обычно это работало, если только Job 1 не строился в то время, когда начался Job 2/3, поскольку он получил бы неполное рабочее пространство. Вы можете обойти это, обнаружив "конец сборки" в Job 1 с помощью файла-дозорника или воспользовавшись плагином блокировок Hudson (я не пробовал).
Вам не нужно использовать настраиваемое рабочее пространство, если вы делаете предположения о размещении других заданий относительно% WORKSPACE%.
Теперь я делаю что-то подобное. Я бы рекомендовал избегать попыток запустить много заданий в одной общей рабочей области. У меня были проблемы с этим.
Я использую maven и тип проектов свободной формы. Один набор заданий выполняется, когда файлы в системе управления версиями запускают его. Они создают локальные артефакты моментальных снимков. Второй набор заданий выполняется каждую ночь и настраивает среду тестирования интеграции, а затем запускает тесты на ней.
Если вы не используете maven; один из вариантов - настроить область на диске и выполнить заключительные шаги в задании, чтобы копировать артефакты в это место. Первые шаги двух рабочих должны состоять в том, чтобы переместить эти файлы. Запустите все, что вам нужно для запуска.
Что касается работы три, теперь есть findbugs/checkstyle/pmd и все плагины для Hudson. Я бы рекомендовал просто создать версию задания 1, которая выполняет чистую ночную проверку и запускает те, которые вы используете на основе кода.
У Hudson нет встроенного репозитория для сборки артефактов. Наше решение состояло в том, чтобы создать его.
Мы находимся в среде Windosw, поэтому я создал общий доступ, доступ к которому можно получить на всех серверах Hudson (мы предоставляем соответствующим службам общую учетную запись, так как системная учетная запись не может получить доступ к ресурсам в сети).
В наших скриптах сборки (ant) у нас есть задачи, которые копируют ресурсы из других заданий в локальную рабочую область и задания, которые генерируют артефакты, копируют их в общий репозиторий.
В других средах вы можете публиковать и получать через FTP или любой другой механизм для перемещения файлов.
Упрощенные примеры публикации и получения заданий:
<!-- ==================== Publish ==================================== -->
<target name="Publish" description="Publish files">
<mkdir dir="${publish.dir}/lib" />
<copy todir="${publish.dir}/lib" file="${project.jar}"/>
</target>
и
<!-- ==================== Get ==================================== -->
<target name="getdependencies" description="Get necessary results from published directory">
<copy todir="${support.dir}">
<fileset dir="${publish.dir}/lib">
<include name="*.jar"/>
</fileset>
</copy>
</target>
Я согласен, что текущие файлы копий/артефакт/рабочее пространство между заданиями вручную меньше, чем элегантные.
Кроме того, я нашел бесполезным пространство/время, чтобы архивировать огромные файлы tgz/zip. В нашем случае эти файлы были огромными (1.5G) и занимали много времени, чтобы упаковать/архивировать/отпечатать/распаковать.
Итак, я решил немного оптимизированный вариант:
git ls-files -oz, не уверен в других SCM