Hudson dependencies

Question

Я создал свою работу hudson A. Работа А зависит от работы B и C. Я установил их с помощью «Построить другие проекты». Это хорошо работает, хотя каждое задание находится в отдельном каталоге в моей рабочей области (структура по умолчанию). Но мне нужны задания B и C в рабочих местах. Рабочая область (корневая папка).

Я рассмотрел два подхода:

1. Изменить рабочее пространство для задания и нажать эту переменную на работу через «Trigger параметризированного сборки на других проектах», а затем использовать скрипт сборки, чтобы скопировать их в этом месте, так как я не мог найти вариант изменить папку, где должно выполняться задание B или C
2. Запуск задания B, а затем C из скрипта сборки как часть задания A. Это делается с помощью удаленных вызовов (найденных где-то в stackoverflow), но этот параметр отсутствует в моей конфигурации, и я не смог найти плагин, который бы его добавил.

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

Причина, по которой я хочу, чтобы это было так просто: работа B - это CMS, которая необходима для работы A, а на задании C есть сценарии python, которые необходимо выполнить до того, как новая версия сможет приземлиться на производственный сервер (это уже сделано с помощью py -муравей).

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

Надеюсь, это имеет смысл.

Answer 1

Подумайте о вакансиях «B» и «C» как о создании «артефактов», которые нужны для работы «A». Затем все, что вам нужно сделать, - это импортировать артефакты, созданные заданиями «B» и «C», когда вы создаете Job «A».

Ваши рабочие места не должны разделять рабочие пространства. В противном случае, что произойдет, если Job «A» будет создан при запуске задания «B» или «C»? У вас будет сразу несколько сборок. Однако, если вы выделите то, что нужно «A» с заданий «B» и «C», вы можете импортировать эти зависимости Job «A». Есть два способа сделать это:

• жестким, но правильного способ: Вы должны создать хранилище релиза, где рабочие места могут принести артефакты, необходимые им. Если это звучит Mavinish вам, ну, это так. Тем не менее, я использовал архитектурный материал Maven без проектов Maven, и он отлично работает. Вы можете использовать что-то вроде Artifactory или Nexus в качестве репозитория выпуска. Затем используйте wget или curl для извлечения элементов из репозитория и использования плагина Maven's deploy:deploy-file, чтобы отправить материал. Вам понадобится Maven (который является процессом Java) для запуска deploy:deploy-file, но вам не нужен проект Maven или даже проект Java. Плагин deploy:deploy-file даже не требует файла Maven pom.xml. Подумайте об этом скорее как утилита командной строки для отправки материала в ваш репозиторий выпуска.
• Простой, но неправильный путь: Hudson имеет Copy Artifacts plugin, что вы можете использовать, чтобы сделать это. Проблема в том, что его легко настроить, но сложно начать отслеживание. Кроме того, это заставляет вас зависеть от очень специфического инструмента. Если вы решите отойти от Хадсона, возможно, вы не сможете дублировать эту функцию.