Я настроил конфигурацию 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;]
У меня есть следующие вопросы:
- Почему код выхода 0 интерпретируется как ошибка?
- Может быть, что-то еще отправляется в стандартную ошибку за кулисами по нашим соображениям?
- Какое решение/обходной путь рекомендует сообщество за пределами конфигурации, предлагаемой 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.
Так
- Это не так. Он терпит неудачу, потому что вы указали, что он должен терпеть неудачу, если что-то записано в stderr, что, похоже, и происходит.
- Некоторые программы записывают сообщения журнала в stderr (например,
az --version
выдают предупреждение в stderr, если оно устарело) - Я думаю, что наиболее простыми решениями являются следующие:
- Если ваши скрипты не используют неисправные приложения, которые завершаются с кодом выхода 0, не используйте этот
failOnStderr
флаг. - Если вам нужно/все еще хочется использовать
failOnStderr
, перенаправьте stderr тех команд, которые записывают свои сообщения в журнал, в stderr (2 > /dev/null
)
- Если ваши скрипты не используют неисправные приложения, которые завершаются с кодом выхода 0, не используйте этот