Работа Дженкинса / Хадсона выше по течению не получает статус "шар" цвета работ ниже по течению

Question

У меня есть задание вверх по течению, которое выполняет 4 задания вниз по течению.

Если вышестоящее задание успешно завершено, нижестоящие задания начинают свое выполнение.

Задание вверх по потоку, поскольку оно успешно завершено, получает синий шар (результат построения = стабильный), но даже если задания вниз по потоку не работают (красный шар) или нестабильны (желтый шар), задание вверх по течению сохраняет свой синий цвет.

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

Answer 1

Я нашел решение.Существует плагин, называемый Groovy Postbuild plugin, который позволяет выполнять скрипт Groovy на этапе посткомпиляции.Добавив простой код к последующим работам, вы можете изменить общий статус вышестоящего.

Этот код вам нужно добавить:

upstreamBuilds = manager.build.getUpstreamBuilds();

upstreamJob = upstreamBuilds.keySet().iterator().next();

lastUpstreamBuild = upstreamJob.getLastBuild();

if(lastUpstreamBuild.getResult().isBetterThan(manager.build.result)) {
    lastUpstreamBuild.setResult(manager.build.result);
}

Более подробную информацию вы можете найти в записи моего блог здесь .

Answer 2

Еще один вариант, который может вам подойти, - использовать плагин параметризованной сборки. Это позволяет вам иметь 4 "нисходящих" билда в качестве шагов сборки. Это означает, что ваша «родительская» сборка может дать сбой, если какая-либо из дочерних сборок сработает.

Мы делаем это, когда хотим скрыть сложность для представления плагина build-pipe .

Answer 3

Возможно, этот плагин делает то, что вы ищете?

Jenkins Необходимое условие сборки Плагин

Answer 4

У нас была похожая проблема, и мы не нашли идеального решения. Частичным решением является использование Promoted Builds Plugin . Сконфигурируйте его для вашего вышестоящего проекта, чтобы он включал некоторый визуальный индикатор, когда закончится нижестоящий проект. Он не меняет общее состояние задания, но уведомляет нас о сбое нижестоящего задания.

Answer 5

Обходной путь для моего проекта - создать новую работу, которая является нисходящим потоком нисходящих потоков.Мы установили шаг после сборки «Параметризованная сборка для других проектов» во всех трех исходных последующих работах.Параметр, который анализируется в новом задании, зависит от состояния трех заданий, и этот параметр заставит новое задание отреагировать соответствующим образом.

1. Создать новое задание, которое содержит один простой класс и одинпростой тест.Оба параметра зависят, т. Е. Класс не работает, если параметр "status" = fail, класс проходит, но тест не проходит, если параметр "status"=unstable и т. Д.

2. Установить триггерную параметризованную сборку в других проектах для трехисходные нижестоящие задания с соответствующими конфигурациями.

3. Установите соответствующее уведомление о новом задании.