Step is succeeding with warning instead of failing after upgrade to 3.5.1

We upgraded our development/testing instance of Octopus to 3.5.1 last week. I noticed that in testing a new package that my step is no longer failing when an error occurs but instead succeeds with warning.

The step is the execution of a SQL file via a custom powershell command. The entire script is wrapped with a try catch that returns -1.

try
{
Invoke-SQLFile “OrcaCLRFunctions.sql” -databaseType “ORCADB”

Invoke-SQLFile "Orca.sql" -databaseType "ORCADB"

}
catch
{
Write-Error $_.Exception
Exit -1
}

And the step does seem to error properly in the UI:

Deploying package ‘E:\Octopus\Files\orcasql.1.1.3.16319-dev.nupkg-d8a79f36-06cf-40e6-8486-1c05785fa31c’ to machine ‘https://devtest.fidlar.com:10933/
Deploying package: E:\Octopus\Files\orcasql.1.1.3.16319-dev.nupkg-d8a79f36-06cf-40e6-8486-1c05785fa31c
Error executing SQL File Orca.sql: System.Management.Automation.RuntimeException: Orca.sql failed to Execute properly.
E:\Octopus\Applications\Dev - WIDaneRep\Dev\orcasql\1.1.3.16319-dev\Deploy.ps1
: System.Management.Automation.RuntimeException: Orca.sql failed to Execute properly.
At E:\Octopus\Applications\Dev - WIDaneRep\Dev\orcasql\1.1.3.16319-dev\Bootstrap.Deploy.ps1:2372 char:1

  • . 'E:\Octopus\Applications\Dev - WIDaneRep\Dev\orcasql\1.1.3.16319-dev\Deploy.ps …
  •   + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
      + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Deploy.ps1
    
    

I saw some discussion about enabling errors to be treated as warnings but do not see anything configuration wise to control this behavior. What is the proper way to make this error out?

Full log is attached, see Step 15.

ServerTasks-2211.log.txt (80 KB)

In looking at previous deployments using the same powershell functions I found an example failure.

09:40:07 Info | Error executing SQL File FtApplicationVw.sql: System.Management.Automation.RuntimeException: FtApplicationVw.sql failed to Execute properly.
09:40:07 Error | E:\Octopus\Applications\Dev - Avid Canary\Dev -
09:40:07 Error | Canary\ftapplication\2016.3.15.16308-dev\Deploy.ps1 :
09:40:07 Error | System.Management.Automation.RuntimeException: FtApplicationVw.sql failed to
09:40:07 Error | Execute properly.
09:40:07 Error | At E:\Octopus\Applications\Dev - Avid Canary\Dev -
09:40:07 Error | Canary\ftapplication\2016.3.15.16308-dev\Bootstrap.Deploy.ps1:1916 char:1
09:40:07 Error | + . 'E:\Octopus\Applications\Dev - Avid Canary\Dev -
09:40:07 Error | Canary\ftapplication\2016.3.1 …
09:40:07 Error | + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
09:40:07 Error | ~~~
09:40:07 Error | + CategoryInfo : NotSpecified: (:slight_smile: [Write-Error], WriteErrorExcep
09:40:07 Error | tion
09:40:07 Error | + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorExceptio
09:40:07 Error | n,Deploy.ps1
09:40:10 Error | Script ‘E:\Octopus\Applications\Dev - Avid Canary\Dev - Canary\ftapplication\2016.3.15.16308-dev\Deploy.ps1’ returned non-zero exit code: 1. Deployment terminated.
09:40:10 Error | Running rollback conventions…
09:40:10 Verbose | Adding journal entry:
09:40:10 Verbose |
09:40:10 Error | Script ‘E:\Octopus\Applications\Dev - Avid Canary\Dev - Canary\ftapplication\2016.3.15.16308-dev\Deploy.ps1’ returned non-zero exit code: 1. Deployment terminated.

The bolded line appears to be what is missing. I will triple check our configuration but there was nothing around this that changed that I am aware of.

One last comment: the second error I posted is using the same syntax/commands as the first deploy script snippet. What stands out at me is that, in the second error, it says the return code is 1, when we’re running Exit -1. I don’t know if that is a symptom of the problem or tangential.

After doing some reading on http://docs.octopusdeploy.com/display/OD/Custom+scripts#Customscripts-Errorhandling I can see that my Write-Error should end script execution, so my Exit -1 never fires. Commenting that out in my catch block does seem to stop execution properly of the deployment. I guess I will experiment with changing these to Write-Warnings instead.