Как условно строить другие проекты?

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

Параметры, которые я хотел бы получить после завершения моей сложной работы:

Ничего не делать
Начните мой проект сборки с низким уровнем риска:
- копирует мой файл WAR в мой репозиторий артефактов
- развертывается в производство
Начните мой проект сборки с высоким риском:
- копирует мой файл WAR в мой репозиторий артефактов
- развертывает для тестирования
- запустить приемочные испытания
- развертывание в производство

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

Я рассмотрел несколько подходов, чтобы сохранить это как одно задание, но пока никто не работал:

Сделайте работу проектом с несколькими конфигурациями (https://wiki.jenkins-ci.org/display/JENKINS/Building+a+matrix+project). Это дает возможность ввести задание с параметром. Я не нашел способ сделать шаг "строить другие проекты" отреагировать на параметр.
Используйте плагин Parameterized-Trigger (https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin). Этот плагин позволяет запускать задания по потоку на основе определенных триггеров. Однако триггеры выглядят слишком ограничительными. Все они основаны на состоянии сборки, а не на любых переменных. Я не вижу здесь никакого параметра, который бы работал для моего использования.
Используйте плагин Flexible Publish (https://wiki.jenkins-ci.org/display/JENKINS/Flexible+Publish+Plugin). Этот плагин имеет противоположную проблему как плагин с параметризованным триггером. У этого есть много полезных условий, которые он может проверить, но не похоже, что он может начать строительство другого проекта. Его действия ограничены деятельностью типа публикации.
Используйте плагин Flexible Publish + Any Build Step (https://wiki.jenkins-ci.org/display/JENKINS/Any+Build+Step+Plugin). Плагин Any Build Step позволяет сделать любое действие сборки доступным для плагина Flexible Publish. В то время как больше действий было доступно после активации этого плагина, эти действия не включали "сборку других проектов".

Действительно ли нет простого способа сделать это? Я удивлен, что я не нашел его и еще больше удивился, что я действительно не видел, чтобы кто-то еще пытался это сделать? Я делаю что-то необычное? Есть ли что-то очевидное, что мне не хватает?

Ответ 1

Если я правильно понял, вы должны сделать это, выполнив следующие шаги:

Первый шаг сборки:
- Регулярно ли работает. В вашем случае: создание, модульное тестирование и упаковка веб-приложения.
- В зависимости от результата пусть он создает файл с определенным именем.
- Это означает, что если вы хотите, чтобы смену низкого риска запускали впоследствии, создайте файл low-risk.prop
Второй этап сборки:
- Создайте триггер/вызов для других проектов. Шаг от параметра-Запуск плагин.
- Введите название своей работы с низким уровнем риска в поле "Проекты для сборки".
- Нажмите: Добавить параметр
- Выберите: Параметры из свойств Файл
- Введите low-risk.prop в свойства Использовать из файла Поле
- Включить Не запускать, если отсутствуют файлы
Третий этап сборки:
- Проверьте, существует ли файл с низким уровнем риска.
- Удалить файл

Сделайте то же самое для работы с высоким уровнем риска

Теперь у вас должна быть следующая установка:

если файл с именем low-risk.prop происходит во время первого этапа сборки, запускается работа с низким уровнем риска.
если файл с именем high-risk.prop происходит во время первого этапа сборки, стартовое задание будет запущено.
если нет .prop Файл ничего не происходит

И это то, чего вы хотели достичь. Не правда ли?

Ответ 2

Вы посмотрели плагин Conditional Build? (https://wiki.jenkins-ci.org/display/JENKINS/Conditional+BuildStep+Plugin)

Я думаю, он может делать то, что вы ищете.

Ответ 3

Если вам нужен условный шаг после сборки, для него есть плагин:
https://wiki.jenkins-ci.org/display/JENKINS/Post+build+task

Он будет искать в консольном журнале для RegEx, который вы указали, и, если найден, выполнит пользовательский script. Вы можете настроить довольно сложные критерии, и вы можете настроить несколько наборов критериев, каждый из которых выполняет разные задачи пост-сборки.

Он не предоставляет вам обычные действия "шаг за шагом", поэтому вы должны написать свой собственный script. Вы можете запускать выполнение одного и того же задания с разными параметрами или другим заданием с некоторыми параметрами стандартными способами поддержки jenkins (например, с помощью curl)

Еще одна альтернатива - плагин для поиска текста Jenkins:
https://wiki.jenkins-ci.org/display/JENKINS/Text-finder+Plugin

Это шаг после сборки, который позволяет принудительно маркировать сборку как "нестабильную", если RegEx находится в тексте консоли (или даже в каком-либо файле в рабочей области). Итак, в ваших шагах сборки, в зависимости от ваших условий, эхо уникальная строка в журнал консоли, а затем выполните RegEx для этой строки. Затем вы можете использовать "Trigger parameterized buids" и установить условие как "неустойчивое". Это имеет дополнительное преимущество: визуальная маркировка сборки отличается (с желтым шаром), однако у вас есть только один условный вариант с этим методом, и из вашего OP, похоже, вам нужно 2.

Попробуйте комбинацию этих двух методов:

Ответ 4

Используете ли вы Ant для своих сборников?

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

Ответ 5

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

Ответ 6

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