Certain PowerShell versions interpret non-errors as errors and end deployments as a failure.

[millerjn21]

Prerequisites

• I have verified the problem exists in the latest version
• I have searched open and closed issues to make sure it isn't already reported
• I have written a descriptive issue title
• I have linked the original source of this report
• I have tagged the issue appropriately (area/*, kind/bug, tag/regression?)

The bug

Certain versions of Windows PowerShell (5.1.17763 and later) will cause Octopus deployments to fail from non-error messages being written to the std-error stream.

What I expected to happen

Non-errors will be output at the appropriate level (progress/warning/etc), and not as a failure.

Steps to reproduce

Step 1: Go to Infrastructure > accounts > add account > azure subscription
Step 2: Fill in: Subscription ID, Tenant ID, Application ID, Application Password / Key, give it a name like AzureAccount
Step 3: Click Save and test
Step 4 Go to Projects > Add Project
Step 5: Unde Deployments choose Process
Step 6: Click Add Step > Azure > Run an azure Script
Step 7: In your new step fill in Step Name as pre-aks preview
Step 8: select Account as your newly created AzureAccount from step 2.
Step 9: In the Script section, under Inline Source Code, add the following script:

az --version

Step 10: click Save
Step 11: Click Add Step > Azure > Run an azure Script again
Step 12: In your new step fill in Step Name as post-aks preview install
Step 13: select Account as your newly created AzureAccount from step 2.
Step 14: In the Script section, under Inline Source Code, add the following script:

$extensions = az extension list | ConvertFrom-Json
if ($extensions.Name -eq "aks-preview") {
    Write-Host "The aks-preview extension is already installed. Nothing to do."
} else {
    Write-Host "Installing the aks-preview extension..."
    az extension add --name aks-preview
}
az --version

Step 15: click Save
Step 16: click Create Release
Step 17: click Save, then Deploy to environment

Expected Results:
Both steps pass, but post-aks preview install will show a warning
Actual Results:
Step 1 passes, but post-aks preview install will will throw an exception (in log exerpt section below):

Screen capture

N/A

Log exerpt

NotSpecified: WARNING: The installed extension 'aks-preview' is in preview.
August 7th 2020 11:23:32
Error
At C:\Octopus\Tentacle\Work\20200807012235-7141-6\Script.ps1:6 char:5
August 7th 2020 11:23:32
Error
+     az extension add --name aks-preview
August 7th 2020 11:23:32
Error
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
August 7th 2020 11:23:32
Error
at <ScriptBlock>, C:\Octopus\Tentacle\Work\20200807012235-7141-6\Script.ps1: line 6
August 7th 2020 11:23:32
Error
at <ScriptBlock>, <No file>: line 1
August 7th 2020 11:23:32
Error
at <ScriptBlock>, C:\Octopus\Tentacle\Work\20200807012235-7141-6\Octopus.AzureContext.ps1: line 190
August 7th 2020 11:23:32
Error
at <ScriptBlock>, C:\Octopus\Tentacle\Work\20200807012235-7141-6\Bootstrap.Octopus.AzureContext.ps1: line 1434
August 7th 2020 11:23:32
Error
at <ScriptBlock>, <No file>: line 1
August 7th 2020 11:23:32
Error
at <ScriptBlock>, <No file>: line 1
August 7th 2020 11:23:33
Fatal
The remote script failed with exit code 1
August 7th 2020 11:23:33
Fatal
The action Run an Azure Script on a Worker failed

Affected versions

This is independent of Octopus Version.

Certain versions of PowerShell, for example, 5.1.17763 and later will have this issue.
This behavior is an intentional change by Microsoft (link below.)

Workarounds

You would need to add $ErrorActionPreference = “silentlycontinue”` before the part that will cause the deployment to fail. After that point, you can change the error preference back to whatever you prefer.

Links

Source ticket: https://help.octopus.com/t/is-there-a-way-to-set-the-erroractionpreference-on-calamari/25477/36
Microsoft post explaining the change: https://devblogs.microsoft.com/powershell/powershell-7-1-preview-6/#make-erroractionpreference-not-affect-stderr-output-of-native-commands

[mcasperson]

Initial investigations in August 2020 on a Windows 2019 VM in Azure showed this behavior, where output to stderr resulted in a Native command error:

A test done yesterday on a Windows 2019 VM in Azure showed this behavior, where output to stderr did not generate a Native command error:

I tried replicating the error described in this issue on Windows 2019 VMs in AWS, Azure and Google Cloud, but could not generate the described failure.

Given the different behavior in Windows VMs between August and now, and the fact that I can not replicate the error, I think this can be put down to a bug in Powershell or Windows that has since been resolved.