Шаг Azure Pipeline завершается ошибкой, хотя код выхода равен 0

Шаг Azure Pipeline завершается ошибкой, хотя код выхода равен 0

Я настроил конфигурацию azure-pipeline yaml с заданием конвейера, которое запускает 5 скриптов. В конфигурации для каждого скрипта failOnStderrустановлен флаг true. Скрипт успешно выполняется, однако этап завершается сбоем с выводом:

##[error]Bash wrote one or more lines to the standard error stream.

Я включил system.debugмногословие и получил следующие подробности:

##[debug]Exit code 0 received from tool '/bin/bash'
##[debug]STDIO streams have closed for tool '/bin/bash'
##[error]Bash wrote one or more lines to the standard error stream.
##[debug]Processed: ##vso[task.issue type=error;]Bash wrote one or more lines to the standard error stream.
##[debug]task result: Failed
##[debug]Processed: ##vso[task.complete result=Failed;done=true;]

У меня есть следующие вопросы:

  1. Почему код выхода 0 интерпретируется как ошибка?
  2. Может быть, что-то еще отправляется в стандартную ошибку за кулисами по нашим соображениям?
  3. Какое решение/обходной путь рекомендует сообщество за пределами конфигурации, предлагаемой azure-pipelines? Я мог бы использовать оболочку, trapно я надеялся найти что-то, что сократит шаблонный код в скриптах.

решение1

У меня также были проблемы, failOnStderrи я пришел к следующему:

Я думаю, что это failOnStderrдолжнотолькоиспользоваться для обработки неисправных приложений, которые возвращают 0, но все равно завершаются ошибкой, и записи причины этой ошибки в стандартный вывод.

В вашем случае сообщение об ошибке, ##[error]Bash wrote one or more lines to the standard error stream.по крайней мере, указывает причину, по которой шаг не был выполнен.

В моем случае сообщение об ошибке было ##[error]Script failed with error: Error: /bin/bash failed with return code: 0таким, что даже не упоминалось о том, что на самом деле произошел сбой из-за сообщения об ошибке (не ошибки), выданного в stderr.

Так

  1. Это не так. Он терпит неудачу, потому что вы указали, что он должен терпеть неудачу, если что-то записано в stderr, что, похоже, и происходит.
  2. Некоторые программы записывают сообщения журнала в stderr (например, az --versionвыдают предупреждение в stderr, если оно устарело)
  3. Я думаю, что наиболее простыми решениями являются следующие:
    • Если ваши скрипты не используют неисправные приложения, которые завершаются с кодом выхода 0, не используйте этот failOnStderrфлаг.
    • Если вам нужно/все еще хочется использовать failOnStderr, перенаправьте stderr тех команд, которые записывают свои сообщения в журнал, в stderr ( 2 > /dev/null)

Связанный контент