El paso de Azure Pipeline falla aunque el código de salida sea 0

El paso de Azure Pipeline falla aunque el código de salida sea 0

He configurado una configuración yaml de azure-pipeline con un trabajo de canalización que ejecuta 5 scripts. La configuración de cada script tiene el failOnStderrindicador establecido en true. El script se ejecuta correctamente, sin embargo, la etapa falla con un resultado de:

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

Habilité system.debugla verbosidad y obtuve más detalles como tales:

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

Tengo las siguientes preguntas:

  1. ¿Por qué el código de salida 0 se interpreta como un error?
  2. ¿Se está enviando algo más al error estándar detrás de escena por nuestra razón?
  3. ¿Qué solución/solución alternativa recomienda la comunidad fuera de la configuración ofrecida por azure-pipelines? Podría usar un shell trap, pero esperaba encontrar algo que redujera el texto repetitivo en los scripts.

Respuesta1

También tuve problemas failOnStderry llegué a lo siguiente:

creo que eso failOnStderrdeberíasolousarse para manejar aplicaciones rotas que devuelven 0 pero aún fallan y escribe el motivo de esa falla en la salida estándar.

En su caso, el mensaje de error ##[error]Bash wrote one or more lines to the standard error stream.al menos indica el motivo por el cual falló el paso.

En mi caso, el mensaje de error ##[error]Script failed with error: Error: /bin/bash failed with return code: 0ni siquiera menciona el hecho de que en realidad falló debido a un mensaje de registro (no un error) emitido a stderr.

Entonces

  1. No lo es. Falla porque usted especificó que debería fallar si se escribiera algo en stderr, lo cual parece ser el caso.
  2. Algunos programas escriben mensajes de registro en stderr (por ejemplo, az --versionemiten una advertencia a stderr si está desactualizado)
  3. Creo que las soluciones más sencillas son las siguientes:
    • Si sus scripts no usan aplicaciones rotas que fallan con un código de salida de 0, no use la failOnStderrbandera
    • Si necesita/aún desea utilizar failOnStderr, redirija stderr de aquellos comandos que escriben sus mensajes de registro a stderr ( 2 > /dev/null).

información relacionada