How does Write-Error works inside a PowerShell run by Octopus Deploy


I’m trying to run some Deploy.ps1 scripts i’ve written to deploy database. When running the script inside PowerShell it works as expected: I have a big try/catch around the main code, when a blocking error happens i throw an exception and the catch block will do a write-error and exit 1. Non blocking error only do a write-error and continue.

When running the script from Octopus Deploy i’ve noticed a strange behavior: it seems that whenever a write-error is called, instead of writing the error it raises an exception. So some non blocking write-error could make the script stop and since i do a write-error in the main catch block before doing an exit 1 the script never return 1.

Is this a standard behavior for powershell script in octopus deploy? Should i only use write-host everywhere?


Hi Guillaume,

When we invoke a PowerShell script, we set $ErrorActionPreference to Stop. This means that any Write-Error causes the script to stop, since for automated deployments we typically don’t want the script to proceed. You can try it out here:

$ErrorActionPreference = "Stop"
Write-Output "Hello"
Write-Error "This is an error"
Write-Output "Goodbye"

To get the normal behavior, the solution is to set $ErrorActionPreference to "Continue" at the top of your script, which overrides what Octopus sets it to.


1 Like

Why is this standard behaviour? I have powershell scripts set up to ignore errors, silently continue etc. but Octopus ignores these settings completely. This isn’t really the behaviour that you’d expect. Furthermore, it doesn’t actually seem to work, as this will fail on the "Get-AzureRmResourceGroup’ with “not found”. This script works fine in “standard powershell”

$ErrorActionPreference = ‘Continue’

Get-AzureRmResourceGroup -Name ‘shr-svc-#{csu}’ -ErrorVariable notPresent -ErrorAction SilentlyContinue
if ($notPresent)
New-AzureRmResourceGroup -Name ‘shr-svc-#{csu}’ -Location ‘#{cluster-location}’


Instead of continuing this discussion in a 3 year old ticket, could you raise a new ticket and give us some more information in regards to your Octopus setup.

  1. What version of Octopus are you running?
  2. Could you please send through the raw log from a deployment where this error occurred

I’ve run the script you included on my local Octopus instance and it runs fine for me, so it could be an environmental thing.