☰

Azure Pipeline-Schritt schlägt fehl, obwohl der Exit-Code 0 ist

tag-icon • tag-icon linux bash shell azure stderr
Azure Pipeline-Schritt schlägt fehl, obwohl der Exit-Code 0 ist

Ich habe eine Azure-Pipeline-YAML-Konfiguration mit einem Pipeline-Job eingerichtet, der 5 Skripte ausführt. In der Konfiguration für jedes Skript ist das failOnStderrFlag auf gesetzt true. Das Skript wird erfolgreich ausgeführt, die Phase schlägt jedoch mit der folgenden Ausgabe fehl:

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

Ich habe system.debugdie Ausführlichkeit aktiviert und weitere Details wie diese erhalten:

##[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;]

Ich habe folgende Fragen:

  1. Warum wird der Exitcode 0 als Fehler interpretiert?
  2. Wird aus unserem Grund im Hintergrund noch etwas anderes an die Standardfehlermeldung gesendet?
  3. Welche Lösung/Umgehung empfiehlt die Community außerhalb der von Azure-Pipelines angebotenen Konfiguration? Ich könnte eine Shell verwenden trap, aber ich hoffte, etwas zu finden, das den Boilerplate-Code in den Skripten reduziert.

Antwort1

Ich hatte auch Probleme mit failOnStderrund kam zu folgendem:

Ich denke, das failOnStderrsolltenurkann verwendet werden, um fehlerhafte Anwendungen zu behandeln, die 0 zurückgeben, aber trotzdem fehlschlagen, und den Grund für diesen Fehler in die Standardausgabe zu schreiben.

In Ihrem Fall gibt die Fehlermeldung ##[error]Bash wrote one or more lines to the standard error stream.zumindest den Grund an, warum der Schritt fehlgeschlagen ist.

In meinem Fall lautete die Fehlermeldung, ##[error]Script failed with error: Error: /bin/bash failed with return code: 0in der nicht einmal erwähnt wurde, dass der Fehler tatsächlich aufgrund einer an stderr ausgegebenen Protokollierungsmeldung (kein Fehler) aufgetreten ist.

Also

  1. Das ist es nicht. Es schlägt fehl, weil Sie angegeben haben, dass es fehlschlagen soll, wenn etwas in stderr geschrieben wird, was der Fall zu sein scheint.
  2. Einige Programme schreiben Protokollierungsmeldungen an stderr ( az --versiongeben beispielsweise eine Warnung an stderr aus, wenn es veraltet ist)
  3. Ich denke, die einfachsten Lösungen sind die folgenden:
    • Wenn Ihre Skripte keine defekten Anwendungen verwenden, die mit einem Exit-Code von 0 fehlschlagen, verwenden Sie das failOnStderrFlag nicht
    • Wenn Sie verwenden müssen/wollen failOnStderr, leiten Sie stderr der Befehle, die ihre Protokollnachrichten schreiben, nach stderr um ( 2 > /dev/null)

verwandte Informationen