Fixed

Held-back steps are reported as skipped. In Get deployment targets, a step held back by the All previous steps succeeded execute condition, or by an earlier step set to stop the deployment, was reported as notRun on every target - as if the deployment had never reached it. It is now skipped, which matches the deployment log. Deployments that ran before this release keep showing notRun for those steps.

Changed

PowerShell 7 steps warn about exit codes. A PowerShell 7 step does not fail on an exit code: only an error the script raises counts, such as throw, or Write-Error when the step is set to fail on errors. PowerShell 5.1 and Python steps do fail on a non-zero exit code, so the same script could succeed in one and fail in the other without any sign of it. A PowerShell 7 script that ends with a non-zero exit now logs a warning saying so. The step still succeeds. The warning comes from the agent, so it appears once your agents are updated to this release.

To fail a PowerShell 7 step on an exit code, check it and throw: if ($LASTEXITCODE -ne 0) { throw "Exited with code $LASTEXITCODE" }.

Documentation. The docs said a non-zero exit code is always recorded as an error. That is true for PowerShell 5.1 and Python only, and Get deployment status now explains what counts as a failing script in each language.

Highlights

  • Fix - steps held back by their execute condition, or after an earlier step stopped the deployment, are reported as skipped by the deployment targets API, not notRun.
  • PowerShell 7 exit codes - a script that ends with a non-zero exit logs a warning; the step still succeeds. Needs the updated agent.
  • Docs - what counts as a failing script is now described per language: PowerShell 7, PowerShell 5.1 and Python.