Hi,
We upgraded to Octopus v2018.7.7 over the weekend and since then all our Classic Azure cloud services fail to deploy. The error we get is:
The step failed: Activity Deploy Get Referral Text Service on the Octopus Server failed with error ‘The account type ‘’ is not valid for this step.’.
All the failing deployments are set up in a similar way:
The deployment script is:
------Start------
#This sets the correct number of Instances for the environment.
$configFile = “ServiceConfiguration.Cloud.cscfg”;
Write-Host "Updating Instance Counts " $configFile
Write-Host “”
if(!(test-path $configFile)){
WriteErrorMsg “Could not find ServiceConfig file named ‘$configFile’!”
Exit 1
}
[xml]$configFileAsXml = Get-Content $configFile
$configFileAsXml.ServiceConfiguration.Role.Instances.Count = [string]$OctopusParameters[“Instances”]
Write-Host “Saving CSCFG”
$configFileAsXml.Save($configFile)
-----end-------
There does not seem to be any place that the Account Type can be specified within the step. Has this method of deployment changed with this upgrade (unfortunately I don’t know what our previous version was).
Thanks
Isabel
Hi Isabel,
Thanks for getting in touch and sorry to hear your Cloud Service steps have ended up in an interesting state. From what I can see in the screenshot and the error you provided, you have ended up in a state somewhere between the pre-2018.5 world and the post-2018.5 cloud target world. So I’m guessing you migrated from somewhere earlier than 2018.5.
We had put a lot of effort in to making sure the existing step would just keep working, with the data setup as it was before 2018.5, in the post 2018.5 world. In the earlier versions you did not have to select any roles in the Execution Plan section of the step, but you had an account to selector and a cloud service and storage account selectors. Like I said the step will actually still work that way today if the data on the step was created in an earlier version.
If you clear the account field though, that’s the signal that you are moving to the new targets world, and then you have to select a role in the Execution Plan, and the validation should stop you from being able to save in the invalid state where there is no role AND no account. This has clearly not worked correctly in your case.
If you have a backup of the database you could restore that and install a version prior to 2018.5. Alternatively, if you create Azure Cloud Service targets in your environments and give them a role that you then set in the Execution Plan, the issue should resolve itself.
We have retried installing earlier versions, setting up the data and then upgrading and in all of our tests the validation stopped us from getting into the state you have. Do you know if the steps were edited at all before you ran the deployments after the upgrade? If there’s anything else that you can remember doing or that happened during the upgrade please let us know, we’d certainly like to track down whatever scenario has caused this.
Look forward to hearing back from you.
Regards
Shannon
Shannon,
The problem I described happened on all of our Classic Cloud Service deployments, These have not changed in many months.
Apart from an issue with certificates there were no problems during the actual upgrade.
We don’t want to go back to an older version of Octopus so I’m working on getting the targets and roles set up.
Regards
Isabel
