☰

即使退出代碼為 0，Azure Pipeline 步驟也會失敗

tag-icon • tag-icon linux bash shell azure stderr
即使退出代碼為 0，Azure Pipeline 步驟也會失敗

我已經設定了一個 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 提供的配置之外，社群還推薦哪些解決方案/解決方法？我可以使用 shell 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)

相關內容