не подведите Дженкинса построить, если выполнить оболочку не удается

Вы можете использовать плагин Text-finder . Это позволит вам проверить консоль вывода для выражения по вашему выбору, а затем отметить сборку как Unstable.

Дженкинс определяет успех / неудачу шага по возвращаемому значению шага. В случае оболочки это должно быть возвращение последнего значения. Для оболочек Windows CMD и (POSIX) Bash необходимо вручную задать возвращаемое значение, используя exit 0в качестве последней команды.

Я смог заставить это работать, используя ответ, найденный здесь:

Как git ничего не совершает без ошибки?

git diff --quiet --exit-code --cached || git commit -m 'bla'

Следующее работает для mercurial только путем фиксации, если есть изменения. Поэтому построить только с ошибкой, если совершить не удается.

hg id | grep "+" || exit 0
hg commit -m "scheduled commit"

Если нет ничего, чтобы нажать git возвращает статус выхода 1. Выполнить построение оболочки шаг отмечен как ошибочный, соответственно. Вы можете использовать оператор OR | | (double pipe).

git commit -m 'some messasge' || echo 'Commit failed. There is probably nothing to commit.'

Это означает, что выполнить второй аргумент, если первый не удался (возвращенное состояние выхода > 0). Вторая команда всегда возвращает 0. Когда нет ничего, чтобы нажать (состояние выхода 1 - > выполнить вторую команду), echo возвратит 0 и шаг сборки продолжается.

Чтобы отметить сборку как нестабильную, вы можете использовать текстовый поиск Дженкинса после этапа сборки. Он может пройти через консольный вывод, сопоставить шаблон (ваше эхо) и отметить сборку как нестабильную.

На (более общий) вопрос в заголовке-чтобы предотвратить неудачу Дженкинса, вы можете запретить ему видеть код выхода 1. Пример для пинг:

bash -c "ping 1.2.3.9999 -c 1; exit 0"

И теперь вы можете, например, получить вывод ping:

output=`bash -c "ping 1.2.3.9999 -c 1; exit 0"`

Конечно, вместо ping ...Вы можете использовать любые команды, включая git commit.

Есть еще один простой способ сказать Дженкинсу, чтобы он не потерпел неудачу. Вы можете изолировать фиксацию на этапе сборки и настроить оболочку так, чтобы она не отказывала:

set +e
git commit -m "Bla."
set -e

Чтобы остановить выполнение, когда команда терпит неудачу:

command || exit 0

Продолжить выполнение при сбое команды:

command || true

Дженкинс выполняет шаги сборки оболочки, используя /bin/sh -xeпо умолчанию. -xозначает печатать каждую выполняемую команду. -eозначает выход с ошибкой, если какая-либо из команд в скрипте не удалась.

Поэтому я думаю, что в вашем случае команда git завершается с 1, и из-за параметра default-eоболочка берет код выхода, отличный от 0, игнорирует остальную часть сценария и помечает шаг как сбой. Мы можем подтвердить это, если вы можете разместить свой сценарий шага сборки здесь.

Если это так, вы можете попробовать поставить #!/bin/sh, чтобы сценарий выполнялся без опции; или сделайте set +eили что-нибудь подобное в верхней части шага сборки, чтобы переопределить это поведение.

Отредактировано: еще одна вещь, которую следует отметить, заключается в том , что, если последняя команда в вашем скрипте оболочки возвращает код, отличный от 0, весь шаг сборки все равно будет помечен как fail даже с этой установкой. В этом случае вы можете просто поставить команду echoв конце, чтобы избежать этого.

Еще один связанный с этим вопрос

Если вы поместите эти команды в оболочку блока:

false
true

ваша сборка будет помечена как fail (по крайней мере 1 ненулевой код выхода), поэтому вы можете добавить (set +e), чтобы игнорировать его:

set +e
false
true

не подведет. Однако это не удастся даже с (set +e) на месте:

set +e
false

потому что последняя команда оболочки должна завершиться с 0.

https://jenkins.io/doc/pipeline/steps/workflow-durable-task-step/#sh-shell-script

если вы включаете свойство returnStatus: true, то возврат оболочки игнорируется.

Для нескольких команд оболочки я игнорирую ошибки, добавляя:

set +e commands true

Еще один ответ с некоторыми советами, может быть полезным для кого-то:

не забудьте разделить ваши команды следующим правилом:

command1 & & command2-означает, что command2 будет выполняться, только если command1 успешна

command1; command2-означает, что команда 2 будет выполнена несмотря на результат command1

например:

String run_tests = sh(script: "set +e && cd ~/development/tests/ && gmake test ;set -e;echo 0 ", returnStdout: true).trim()
println run_tests 

будет успешно выполняться с set -eи echo 0, если gmake testне удался (ваши тесты не прошли), в то время как следующий код обрезан:

String run_tests = sh(script: "set +e && cd ~/development/tests/ && gmake test && set -e && echo 0 ", returnStdout: true).trim()
println run_tests 

немного не так, и команды set -e и echo 0 в&& gmake test && set -e && echo 0 будет пропущен, с println run_tests заявление, потому что не удалось gmake test прервет Дженкинс построить. В качестве обходного пути вы можете переключиться на returnStatus:true, но тогда вы пропустите выходные данные своей команды.