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

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

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

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

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

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

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

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

Ответ 1

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

http://wiki.hudson-ci.org/display/HUDSON/Copy+Artifact+Plugin

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

Вы посмотрели на Hudson wiki? В частности: Разделение большой работы на более мелкие задания

Ответ 5

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

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

Ответ 6

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

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

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

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

Ответ 7

У 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>

Ответ 8

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

Кроме того, я нашел бесполезным пространство/время, чтобы архивировать огромные файлы tgz/zip. В нашем случае эти файлы были огромными (1.5G) и занимали много времени, чтобы упаковать/архивировать/отпечатать/распаковать.

Итак, я решил немного оптимизированный вариант:

Работа 1/2/3 все проверяет/клонирует тот же исходный репозиторий, но
Работа 1 только упаковывает файлы, которые фактически создают артефакты
- с Git делает это легко и быстро git ls-files -oz, не уверен в других SCM
использовать плагин Copy Artifact для передачи файлов
Это уменьшает эти файлы до 1/3 размера в нашем случае → ускорение, меньше пространства впустую