After updating to 2018.3.8 (from previous 3.x version), we’ve encountered an issue with our deployment steps to Azure. There have been a few other variables at play here, but we’ve yet to identify root cause.
We updated Octopus deploy to the latest version
We’ve switched to the latest ‘Service Account’ based deployment so that we can use the resource manager scripts, as necessary for our PremiumV2 web apps (not able to publish using previous *-AzureWebsite commands)
Upon trying to run, we’re getting an exception; this is due to the publishing location being incorrect
Looking at the publishing profile retrieved from Get-AzureRMWebAppSlotPublishingProfile, the address is correct. However, when the profile is retrieved via Octopus, it doesn’t match the value retrieved with the above powershell call. In our particular case, the name of the web app is being shortened on azure by 1 character - so if the name were “WebApplication” and slot “Staging”, Azure is returning WebApplicatio-Staging.scm.azurewebsites.net:443 but Octopus deploy is attempting to use WebApplication-Staging.scm.azurewebsites.net:443 (note the n on Application).
Due to this discrepancy - all of our Azure deployments are currently unable to publish properly.
Are there unique methods used to construct publishing profiles for slot-based deployments in Octopus? I’d assume here that we’d be getting identical returned values from Azure for the publishing url - but that doesn’t seem to be the case here.
We’ve come across this issue in the past and have reported it to Microsoft here. For WebApps with names longer than 40 characters, the Azure API will truncate the name in the URL when we attempt to get the publishing credentials. This issue has not yet been resolved.
Can you confirm this is what’s happening in your case and that the “WebApplication” name is longer than 40 characters?
The only option we can recommend is to use shorter names for Web Apps to ensure you don’t reach this 40-character limit. Is that an option you can consider?
We did some initial investigation on resource naming last week and were able to identify that shorter-named resources were able to be deployed properly using Octopus - so we’ve gone through and altered our naming patterns to ensure shorter resource names across the board.
With that, all resources are able to deploy successfully again.
This is kind of important issue and inconvenience for us because we can’t follow our Azure resource naming conventions due to this problem. For some time there was not so many resources with long names causing this problem, but recently we got new customer with longer name which makes our webapp names in Azure become longer (according to naming pattern we use customer name in every Azure resource) thus also pushes very close to this name length problem and we experience it more often now and it’s really difficult to think of any well-describing name with e.g. 3 characters left for the postfix.
But it seems like it would be rather easy to fix this in Octopus because it’s possible to retrieve valid scm hostname/url (truncated one) from the Azure ARM API and then use that one where needed in Azure deploy step.
What do you think?