Thanks for the additional information and sending your process export through Aleksandras.
Sorry I should have mentioned, that SmartFile/upload location is only visible to Octopus staff and will be deleted when we’ve finished the analysis of your file. Your process won’t be imported anywhere and will only be read manually, so we can see what scripting is being done.
We setup a mini version of your deployment process using our subscription, but unfortunately we haven’t been able to reproduce this yet. But we do think there are some options worth exploring…
One thing that stood out slightly was the use of
Save-AzureRmContext in your “Cleanup old ARM deployments” step. We initially thought this may potentially be causing some things to stomp on each other, but if it’s just saving the auth information to a file so it can be used in a separate process (via
Start-Job and the
Import-AzureRmContext), this shouldn’t be a problem. To rule it out though, you could temporarily disable this cleanup step and see if it has any effect.
Between those versions of Octopus you mentioned, we have upgraded the Azure PowerShell Cmdlets from 5.8 to 6.11, so we’re wondering if something here may be different all of a sudden. To test that theory, you could install your own version of the Azure PowerShell modules instead of the ones we bundle (try grabbing an older version 5.8, or even try the latest version (6.13 I believe), and configuring Octopus to use your custom version instead (see instructions here).
Another possibility (although we think unlikely), may be coming from the introduction of the Azure CLI since your upgrade. Since you don’t appear to be using the CLI anywhere in your scripts, you could try disabling this Azure CLI feature altogether by creating an
OctopusDisableAzureCLI variable and setting its value to
True. Full details here, then monitor to see if that change has any effect on your deployments.
Sorry we don’t have any exact answers at this stage, but hopefully we can get a reproduction to narrow things down.