Azure-pipelines-tasks: The Azure CLI Task does not fail when a command fails

[jlorich]

Required Information

Type: Bug
Task Name: Azure CLI

Environment

Server: Azure Pipelines
Account Name: mtcdenver
Project Name: Azure Demos
Build Definition Name: demo-whack-a-mole-admin
Build Number: #20190401.2
Agent: Hosted

Issue Description

When a command within the Azure CLI task fails, subsequent commands within the script continue to run and the task is marked as successful, causing the build or release process to conitnue. The Azure CLI task _only_ fails if there is a failing exit code on the last command, which is not how any script runner should be expected to work.

Any failing exit code returned from any command should immediately terminate the script and mark the task as failed.

Task logs

Relevant log snippet:

2019-04-01T23:40:40.9454429Z /bin/sh: 1: slkjdflsdkjfsd: not found
2019-04-01T23:40:40.9455322Z The command '/bin/sh -c slkjdflsdkjfsd' returned a non-zero code: 127
2019-04-01T23:40:40.9455855Z 2019/04/01 23:40:39 Container failed during run: build. No retries remaining.
2019-04-01T23:40:40.9456310Z failed to run step ID: build: exit status 127
2019-04-01T23:40:40.9456648Z 
2019-04-01T23:40:40.9457059Z Run ID: cj1t failed after 1m25s
2019-04-01T23:40:40.9671327Z ERROR: Run failed

However the task continues to run other commands after, and marks itself as successful.

Full Debug Logs

[cwiederspan]

We have run into this issue with a customer project that looking to bring a large Heroku app into Azure and Azure DevOps. Would be great if this script worked like many/most of the others out there.

[jlorich]

I often recommend use of the Azure CLI task to build and push containers as well, as it's nice to be able to interact with ACR without creating a seperate service principal. However with how things are designed now I need an incredibly over complicated script to check each previous lines success and only continue if it's really working.

[amaljg]

@jlorich @cwiederspan The Azure CLI task relies on the scripting environment’s behaviour. For inline scripts, the task actually creates a batch script (in Windows) or bash script (in Linux) with the specified commands and executes the script. So the behaviour of whether to exit on individual command failure or not is dependent on the script & scripting environment. The default behaviour for batch script (Windows) is to exit on failure, while the same for bash script (Linux) is to continue irrespective of return code.

@jlorich Since you are running the script on Ubuntu agent, your script is simply continuing further without considering the return code of individual commands. If you want to alter this behaviour, you need to modify your script appropriately – either explicitly check for command return code for specific commands or alter the script execution behaviour. E.g., in order to achieve the latter in Ubuntu, you can probably add “set -e” command to the start of your script.

Let us know if this doesn't work for you.

[jlorich]

Thanks for the insights @amaljg. Perhaps this is just a lacking in the documentation then, as both myself and a number of others have ran into this in the past - especially with inconsistencies depending on the agent that is running. I think this has led to a number of various issues that have been filed here in the past too. For an external script file, setting set -e makes sense, for an inline script to me that was already the expected behavior. It gets especially confusing since there are "fail on standard error" and "continue on error" options in the GUI, but neither really perform what I feel the general expectation would be.

To me having adding an option that sets set -e for you, and tweaking the option descriptions may help prevent this confusion in the future. For example, if the options were:

• Fail task immediately if a command fails
• Fail task after script execution on StandardError

This would make it quite clear what is happening, and also provide the option to write a release task that is not dependent on the underlying agents behavior.

[amaljg]

Thanks @jlorich for the feedback. Adding @pulkitaggarwl to consider the feedback in the next version of the task. For now, since you are unblocked, I'm closing this issue. Feel free to reach out to us, if you need any further help.