CI does not fail on multiline script errors

[sunjay]

We have a few multiline scripts in our Azure DevOps Pipeline. For example:

turtle/azure-pipelines.yml

Lines 61 to 66 in dc80b65

	- script: |
	rustc --version --verbose
	cargo build --verbose --all
	cargo build --verbose --all --features "unstable"
	cargo build --verbose --all --examples --features "unstable"
	cargo test --verbose --all --features "test unstable" --no-run

Originally when I set this up, I expected that if any of those lines failed, the whole step would fail, but apparently that is not the case.

Related GitHub issue: microsoft/azure-pipelines-yaml#135

This means that it is theoretically possible for our CI to let through build errors, test failures, or worse. Any help fixing this would be appreciated. This is a terrible default, but we'll just need to work around it however we can.

Note that it isn't enough to just add set -e at the top of the script since that won't work on Windows.

[cape-dev]

any news on this? how is such a default behaviour even possible?

[ryancdotnet]

I'm looking for a resolution on this too. In my specific case, I'm running these multi-line script tasks on an on-premise hosted Windows VM. I expected that when a multi-line script has any failures that that script task fails, and thus would fail the job. Instead, the job continues to run, which is like a derailed train at that point.

Is there a workaround to this behavior via some job setting or script task setting?

[ryancdotnet]

I'm looking for a resolution on this too. In my specific case, I'm running these multi-line script tasks on an on-premise hosted Windows VM. I expected that when a multi-line script has any failures that that script task fails, and thus would fail the job. Instead, the job continues to run, which is like a derailed train at that point.

Is there a workaround to this behavior via some job setting or script task setting?

UPDATE: I resolved my issue. My problem was I was using condition: ... on subsequent tasks, and I did not understand that this overwrote the default behavior. This is all described in the docs, but when you provide a condition expression, you lose the default behavior of skipping a task if the previous (or custom dependsOn:...) task fails. To re-enable this, you use something similar to the following:

 - script: |
     echo Test
  condition: and(succeeded(), OTHER__CUSTOM_CONDITON_HERE)

Side note: if you were previously using parameters in your condition, you no longer can do that because you need to evaluate the condition at run time (i.e. you can't just put in "false" or something ahead of time). To use a parameter in a condition like this, I simply stored my parameter value as a variable, then just used that variable in the run-time evaluation of the condition.