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 failOnStderr
indicador 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.debug
la 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:
- ¿Por qué el código de salida 0 se interpreta como un error?
- ¿Se está enviando algo más al error estándar detrás de escena por nuestra razón?
- ¿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 failOnStderr
y llegué a lo siguiente:
creo que eso failOnStderr
deberí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: 0
ni siquiera menciona el hecho de que en realidad falló debido a un mensaje de registro (no un error) emitido a stderr.
Entonces
- No lo es. Falla porque usted especificó que debería fallar si se escribiera algo en stderr, lo cual parece ser el caso.
- Algunos programas escriben mensajes de registro en stderr (por ejemplo,
az --version
emiten una advertencia a stderr si está desactualizado) - 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
failOnStderr
bandera - Si necesita/aún desea utilizar
failOnStderr
, redirija stderr de aquellos comandos que escriben sus mensajes de registro a stderr (2 > /dev/null
).
- Si sus scripts no usan aplicaciones rotas que fallan con un código de salida de 0, no use la