Совместное использование артефактов сборки между рабочими местами в Гудзоне - PullRequest
33 голосов
/ 06 мая 2009

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

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

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

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

Я попытался использовать функцию «Дополнительные параметры проектов> использовать настраиваемое рабочее пространство», чтобы код, скомпилированный в задании 1, можно было использовать в заданиях 2 и 3. Однако кажется, что все артефакты сборки остаются в этом рабочем пространстве задания 1. Я делаю это правильно? Есть ли лучший способ сделать это? Я думаю, что я ищу что-то похожее на настройку конвейера сборки ... чтобы можно было делиться вещами и выполнять соответствующие задания поэтапно.

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

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

Ответы [ 8 ]

15 голосов
/ 09 ноября 2010

Возможно, вы захотите попробовать плагин Copy Artifact:

http://wiki.hudson -ci.org / дисплей / HUDSON / Copy + Артефакт + Plugin

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

7 голосов
/ 26 марта 2010

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

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

2 голосов
/ 17 июня 2009

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

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

1 голос
/ 10 мая 2009

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

0 голосов
/ 05 ноября 2011

Я согласен, что текущая копия файлов / артефактов / рабочих пространств между заданиями вручную не слишком элегантна.

Кроме того, я обнаружил, что для архивации огромных файлов tgz / zip необходимо тратить пространство / время. В нашем случае эти файлы были огромными (1,5 ГБ) и занимали много времени, чтобы упаковать / архивировать / отпечатки пальцев / распаковать.

Итак, я остановился на слегка оптимизированном варианте того же:

  • Задания 1/2/3 все извлекают / клонируют один и тот же исходный репозиторий, но
  • В задании 1 упаковываются только файлы, которые на самом деле являются артефактами сборки.
    • с Git делает это простым и быстрым git ls-files -oz, не уверенный в других SCM
  • использовать плагин Copy Artifact для передачи файлов
  • В нашем случае это уменьшает размер этих файлов до 1/3 -> ускорение, меньше места впустую
0 голосов
/ 12 июня 2009

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

Мы находимся в среде 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 голосов
/ 12 мая 2009

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

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

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

Что касается задания три, то сейчас есть findbugs / checkstyle / pmd и все плагины для Hudson. Я бы порекомендовал просто создать версию задания 1, которая выполняет чистую ночную проверку и запускает ее на основе кода.

0 голосов
/ 10 мая 2009

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

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

...