Пометка вверх по течению Jenkins / Hudson как неудачной, если не удается выполнить работу вниз по течению

Question

Я использую Параметризованный триггерный плагин , чтобы запустить последующую сборку.

Как мне указать, что моя работа в восходящем направлении должна завершиться неудачей в случае отказа в нисходящем направлении? Задание вверх по течению на самом деле является фиктивным заданием с параметрами, передаваемыми вниз по потоку.

Answer 1

Убедитесь, что вы используете правильный шаг для выполнения ваших последующих заданий; Я обнаружил, что, так как я выполнял мой как «шаг после сборки», у меня не было опции «Блокировать, пока запущенные проекты не закончат свои сборки». Изменение этого слова на «задача сборки» в отличие от «задачи посткомпоновки» позволило мне найти нужные параметры в плагине Parameterized Trigger.

Answer 2

этот код помечает нестабильную / неудачную сборку в восходящем потоке в зависимости от состояния задания в нисходящем направлении.

/*************************************************
Description: This script needs to put in Groovy 
Postbuild plugin of Jenkins as a Post Build task.
*************************************************/

import hudson.model.*

void log(msg) {
  manager.listener.logger.println(msg)
}

def failRecursivelyUsingCauses(cause) {
     if (cause.class.toString().contains("UpstreamCause")) {
        def projectName = cause.upstreamProject
        def number = cause.upstreamBuild
        upstreamJob = hudson.model.Hudson.instance.getItem(projectName)
        if(upstreamJob) {
             upbuild = upstreamJob.getBuildByNumber(number)
             if(upbuild) {
                 log("Setting to '" + manager.build.result + "' for Project: " + projectName + " | Build # " + number)
                 //upbuild.setResult(hudson.model.Result.UNSTABLE)
                 upbuild.setResult(manager.build.result);
                 upbuild.save()

                 // fail other builds
                 for (upCause in cause.upstreamCauses) {
                     failRecursivelyUsingCauses(upCause)
                 }
             }
        } else {
            log("No Upstream job found for " + projectName);
        }
    }
}


if(manager.build.result.isWorseOrEqualTo(hudson.model.Result.UNSTABLE)) {
    log("****************************************");
    log("Must mark upstream builds fail/unstable");
    def thr = Thread.currentThread()
    def build = thr.executable
    def c = build.getAction(CauseAction.class).getCauses()

    log("Current Build Status: " + manager.build.result);
    for (cause in c) {
        failRecursivelyUsingCauses(cause)
    }
    log("****************************************");
}
else {
    log("Current build status is: Success - Not changing Upstream build status");
}

Answer 3

Посмотрите на следующий ответ: Fail Hudson build с отличным скриптом .Вы можете получить доступ к исходному заданию и потерпеть неудачу при его сборке, НО ... будьте осторожны с тем фактом, что действия Хадсона / Дженкинса после сборки прямо сейчас не позволяют указывать какой-либо порядок: если ваш Groovy-скрипт указан помимо других пост-сборокдействия, и эти действия влияют на результат сборки (т. е. на разбор результатов теста), тогда вы не сможете обновить состояние вышестоящего задания, если Jenkins решит запустить их после вашего groovy-скрипта.

Answer 4

На шаге «Построение» настройте сборки Trigger / Call для других проектов, выберите последующее задание. Выберите «Блокировать, пока запущенный проект не завершит их сборку». Сохраните настройки по умолчанию под ним. Эти настройки приведут к сбою задания в восходящем направлении, а сбой в нисходящем направлении.