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

Я пытаюсь настроить наш процесс сборки в Гудзоне.

Задание 1 будет супер быстрым (надо надеяться), непрерывное задание сборки интеграции, которое будет часто создаваться.

Задание 2, будет ответственно за выполнение комплекта комплексного испытания, в равном интервале или инициированный вручную.

Job 3 будет ответственен за рабочие аналитические инструменты через кодовую базу (во многом как Job 2).

Я пытался использовать функцию "Advanced Projects Options> use custom workspace" так, чтобы код, скомпилированный в Job 1, мог использоваться в Job 2 и 3. Однако кажется, что все артефакты сборки остаются в той рабочей области Job 1. Я - я делающий это правильно? Существует ли лучший способ сделать это? Я предполагаю, что ищу что-то подобное конвейерной установке сборки... так, чтобы вещи могли быть совместно использованы, и соответствующие задания могут быть выполнены шаг за шагом.

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

Любые предложения одобрены.Спасибо!

33
задан ShiDoiSi 22 August 2012 в 17:12
поделиться

6 ответов

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

1
ответ дан 27 November 2019 в 19:32
поделиться

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

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

0
ответ дан 27 November 2019 в 19:32
поделиться

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

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

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

Что касается третьего задания, теперь есть findbugs / checkstyle / pmd и все плагины для Hudson. Я'

0
ответ дан 27 November 2019 в 19:32
поделиться

Хадсон, похоже, не имеет встроенного репозитория для артефактов сборки. Нашим решением было создать его.

Мы находимся в среде 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>
0
ответ дан 27 November 2019 в 19:32
поделиться

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

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

2
ответ дан 27 November 2019 в 19:32
поделиться

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

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

7
ответ дан 27 November 2019 в 19:32
поделиться
Другие вопросы по тегам:

Похожие вопросы: