Octopus.Action.Azure.SubscriptionId seems to default to the wrong subscription

The goal: Add/Update an Azure Web App setting with the Octopus Release info.
The problem: One of my Tenants uses an Azure Account with access to two subscriptions, and I can not find the correct subscriptionId for one of the deployment targets.

I have a powershell script that basically does this:

$subId = $OctopusParameters["Octopus.Action.Azure.SubscriptionId"]
$rg = $OctopusParameters["Octopus.Action.Azure.ResourceGroupName"]
$webAppName = $OctopusParameters["Octopus.Action.Azure.WebAppName"]
$sourceSlot = $OctopusParameters["Octopus.Action.Azure.DeploymentSlot"]
$octoVersion = $OctopusParameters["Octopus.Release.Number"]
$settings = "octopusversion=$octoVersion"
$addCmd = "az webapp config appsettings set --subscription $subId -g $rg -n $webAppName -s $sourceSlot --settings $settings"
write-verbose "start cmd: $addCmd"
Invoke-Expression $addCmd

I get the correct values for

  • WebAppName
  • ResourceGroupName
  • DeploymentSlot

And the wrong value for

  • SubsriptionId

Obviously the “az webapp config…” command fails (with error that it can not find the resource group, since it is running in the wrong context).
My initial thought was that I could just set the correct subscriptionId myself in the script with “az account set --subscription $subId”, but the $subId resolves to the subscription that does not match the WebAppName/ResourceGroup.

So the question is two-fold:

  • Is there some other system variable that contains the subscriptionId for the Deployment Target that I am missing?
  • Should the $OctopusParameters[“Octopus.Action.Azure.SubscriptionId”] point to the actual subscription for the matching $OctopusParameters[“Octopus.Action.Azure.WebAppName”] (i.e. is this a bug)?

Hi @karl1,

Thanks for reaching out, and sorry to hear your deployment isn’t working for you as expected.

Just to make sure we’re on the same page, you’re using the “Deploy an Azure App Service” step to deploy to an Azure WebApp infrastructure target, and you’re finding that the subscriptionID being populated in that deployment doesn’t correlate to the account that is configured on that target?

If so, I have not been able to replicate this in my local testing - the subscriptionID always lines up with the Azure account associated with the Azure WebApp target. If you needed something other than the subscription on the account, you would likely need a second Azure account configured, and the WebApp target configured to use that instead.

I hope this helps, but please let me know if my interpretation of your ticket is incorrect.

Hi,

The subscriptionId matches one of the subscriptions the account have access to, it does not match the correct subscriptionID (where the web app resides).

To reproduce, try to create:

  • Two azure subscriptions
  • one web app in each subscriotion
  • set up both apps as a deployment target
  • One Azure Account with access to both subscriptions

Run one “az web abb…” command against each web app with the same azure account

Pretty sure that will reproduce the bahaviour.

Thanks for the clarification, Karl

As the Subscription ID is part of Octopus’ Azure account configuration, I don’t think it would work in this scenario. You would likely need a distinct Azure account for each subscription, with the two Octopus webapp deployment targets configured to use the account with the correct subscription for the intended Azure webapp.

Hi and thanks for the clarification.

I guess a feature request then, for Octopus to store SubscriptionId in the same manner as the ResourceGroup is stored for resources that resides in Azure. Then managing the resources would be possible by having the value available. It is literally needed if you at any point want to manage a resource that is not located in the account’s default subscription, and the information is certainly available when Octopus gets the web app’s ResourceGroupName.

Hi Karl,

This isn’t a use case that we’ve come across previously. I suspect that other users have ended up creating separate Azure accounts and deployment steps for each subscription.

I can see how this could be cumbersome if you have a number of subscriptions that could all be accessed by the same Service Principal though.

I’ve had a look through our user voice site and don’t see any similar suggestions, so, it would be worthwhile to raise this idea there.

Regards,
Paul

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.