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

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

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


person Quintin Par    schedule 19.06.2011    source источник


Ответы (4)


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

введите описание изображения здесь

person Andrew    schedule 13.02.2013
comment
Единственное, что я бы добавил, так это то, что заблокированное задание по-прежнему занимает исполнитель сборки, поэтому для длинных конвейеров вам нужно помнить об этом. Тем не менее, большое спасибо за этот ответ - я сам пытался сделать то же самое и даже не думал об использовании шага сборки. - person Jason; 14.04.2015
comment
тогда это использует плагин postbuild-task? - person grepit; 27.06.2016

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

/*************************************************
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");
}
person QE Expert    schedule 05.02.2015
comment
Можно ли сделать так, чтобы он пометил восходящие задания как УСПЕШНО в случае восстановления отказавшего нисходящего задания? - person yair; 14.04.2016
comment
Можно ли изменить статус даже после того, как родительское восходящее задание ЗАВЕРШЕНО? - person Anton Krug; 15.08.2018


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

person Daniel Abraham    schedule 12.05.2019