Совместное использование артефактов сборки между заданиями в Гудзоне

Вы смотрели вики-страницу Hudson? В частности: Разделение большой работы на более мелкие.

У меня была такая же проблема, и в итоге я выбрал отдельные проекты для долгосрочных задач. Первым шагом в этих проектах было копирование всех файлов из рабочей области задания 1 (т.е. последней сборки) в рабочие области задания 2/3 / и т.д. Обычно это срабатывало, если только задание 1 не создавалось в то время, когда задание 2/3 начиналось, поскольку оно получало неполное рабочее пространство. Вы можете обойти это, обнаружив «конец сборки» в Задании 1 с помощью сигнального файла или используя плагин Hudson locks (я не пробовал).

У вас нет , чтобы использовать пользовательское рабочее пространство, если вы делаете предположения о размещении других заданий относительно% WORKSPACE%.

Я сейчас делаю что-то подобное. Я бы рекомендовал избегать любых попыток запустить множество заданий в одной и той же общей рабочей области. У меня только с этим были проблемы.

Я использую maven и тип проектов свободной формы. Один набор заданий запускается, когда его запускают файлы в системе контроля версий. Они создают локальные артефакты моментальных снимков. Второй набор заданий запускается каждую ночь и настраивает среду тестирования интеграции, а затем запускает в ней тесты.

Если вы не используете maven; Один из вариантов - создать область на диске и выполнить последние шаги в первом задании: скопировать артефакты в это место. Первым шагом второго задания должно быть перемещение этих файлов. Выполните все, что вам нужно для запуска.

Что касается третьего задания, теперь есть findbugs / checkstyle / pmd и все плагины для 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>

Да, эта вики-страница была не очень полезной, потому что она пыталась придать ей элегантный вид. Правда в том, что Hudson не очень элегантно поддерживает цепочки заданий, если вам нужно передавать данные от одного задания к другому.

Я также использую метод zip-up-and-copy-workspace для передачи рабочих пространств из одного работа к другому. У меня есть быстрая сборка, полная аналитическая сборка, а затем сборки дистрибутива. В промежутках я использую Ant для генерации меток времени и «штампов сборки», чтобы отмечать, номер какого задания был построен, какой номер другого задания. Функция снятия отпечатков пальцев помогает отслеживать файлы, но, поскольку я не собираюсь архивировать zip-архивы рабочего пространства, снятие отпечатков пальцев бесполезно для пользователей, поскольку они фактически не могут видеть zip-архивы рабочего пространства.

У Hudson есть плагин для решения этой проблемы: http://wiki.hudson-ci.org/display/HUDSON/Clone+Workspace+SCM+Plugin (ссылка в настоящее время не работает)

Соответствующая страница Jenkins находится здесь: https://wiki.jenkins-ci.org/display/JENKINS/Clone+Workspace+SCM+Plugin