Azure Pipeline Step Fails Even Though Exit Code is 0

Question

I have set up an azure-pipeline yaml config with a pipeline job that runs 5 scripts. The config for each script has the failOnStderr flag set to true. The script runs successfully, however the stage fails with an output of:

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

I enabled system.debug for verbosity and got further details as such:

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

I have the following questions:

1. Why is the exit code of 0 being interpreted as an error?
2. Is something else being sent to standard error behind the scenes for w.e. reason?
3. What solution/workaround does the community recommend outside of the config offered by azure-pipelines? I could use a shell trap but I was hoping to find something that would reduce boilerplate across the scripts.

Answer 1

I also had problems with failOnStderr and came to the following:

I think that failOnStderr should only be used to handle broken applications that return 0 but still fail and write the reason for that failure to stdout.

In your case the error message ##[error]Bash wrote one or more lines to the standard error stream. at least gives the reason why the step failed.

In my case the error message was ##[error]Script failed with error: Error: /bin/bash failed with return code: 0 which doesn't even mention the fact that it actually failed due to a logging message (not an error) issued to stderr.

So

1. It is not. It fails because you specified that it should fail if something was written to stderr, which seems to be the case
2. Some programs write logging messages to stderr (e.g. az --version issues a warning to stderr if it is outdated)
3. I think the easiest solutions are the following:
   • If your scripts don't use broken applications that fail with an exit code of 0, don't use the failOnStderr flag
   • If you need/still want to use failOnStderr, redirect stderr of those commands that write their logging messages to stderr (2 > /dev/null)