Есть ли способ использовать «тип распространения» в Jenkinsfile с декларативным синтаксисом непосредственно для stage / step?

Question

Вы можете использовать размножение в задании на сборку, как описано здесь:

https://jenkins.io/doc/pipeline/steps/pipeline-build-step/

Таким образом, вы можете использовать что-то подобное, чтобы предотвратить неудачный шаг при сбое полной сборки:

build(job: 'example-job', propagate: false)

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

Если я не могу подавить распространение на этапе / шаге, есть ли способ использовать вызов build (), чтобы сделать то же самое?Может быть, если я переместить его в другой конвейер и вызвать это через build ()?

Любая помощь приветствуется.

Answer 1

В настоящее время существует множество предложений для синтаксиса в сценарии , но для декларативного синтаксиса ведется работа по его поддержке.

Отслеживайте ход выполнения https://issues.jenkins -ci.org / browse / JENKINS-26522 , который объединяет все части вместе для достижения этой цели. У него есть некоторые интересные биты, уже помеченные как «Разрешенные» (что означает изменение кода), такие как https://issues.jenkins -ci.org / browse / JENKINS-49764 («Разрешить определять пользовательский статус для конвейера» этап"). К сожалению, я не могу найти ссылки ни на один из билетов, включенных в журнал изменений Jenkins, который имел бы смысл, так как родительский билет еще не закончен.

Интересно также следующее: https://issues.jenkins -ci.org / browse / JENKINS-45579 , которое было вновь открыто из-за проблемы. Среда для этого:

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

Еще один интересный билет - "Отдельные шаги и этапы / блоки конвейера должны иметь статусы результата" , для которых мне удалось найти соответствующий PR: https://github.com/jenkinsci/workflow-api-plugin/pull/63

---

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

Для нужд, подобных той, о которой вы заявили, при наличии достаточного количества шума декларативный конвейер, вероятно, со временем будет изменен для его поддержки.

Answer 2

С помощью catchError вы можете предотвратить неудачный шаг при сбое полной сборки:

pipeline {
    agent any
    stages {
        stage('1') {
            steps {
                sh 'exit 0'
            }
        }
        stage('2') {
            steps {
                catchError(buildResult: 'SUCCESS', stageResult: 'FAILURE') {
                    sh "exit 1"
                }
            }
        }
        stage('3') {
            steps {
                sh 'exit 0'
            }
        }
    }
}

В приведенном выше примере все этапы будут выполнены, конвейер будет успешным, но этап 2 будет отображаться как неудачный:

Как вы уже догадались, вы можете свободно выбирать buildResult и stageResult, если хотите, чтобы они были нестабильными или что-то еще. Вы даже можете отменить сборку и продолжить выполнение конвейера.

Просто убедитесь, что ваш Jenkins обновлен, поскольку это довольно новая функция.