Set Azure account to use from output variable of a step?

I’m wondering if it is possible to specify the name (or account id) of an Azure subscription as the output variable of a step, such that subsequent steps can use this variable to .

The reason being I want to alternate between a pool of subscriptions that host an application in a test environment; e.g. on even days use Joe’s subscription for deployments to acceptance testing, on odd days use Jane’s subscription for these deployments (additional background: Azure Automation will tear down these environments at the end of the work day, a TeamCity scheduled build will deploy to these environments with Octopus Deploy’s assistance in the morning).

However I get the error message;

The expression #{Octopus.Action[‘Set AzureSubscriptionId’].Output.AzureSubscriptionId} could not be expanded to an Account ID.

where ‘Set AzureSubscriptionId’ is the name of the script step that runs a bit of Powershell to determine which subscription should be used (“it’s an even day, and deploying to Integration Testing, use Jill’s subscription!” “it’s an odd day, and deploying to Acceptance Testing, use Jack’s subscription!”). ‘AzureSubscriptionId’ is the name of the output variable that is set by the ‘Set AzureSubscriptionId’ step.

I was originally using the name of the Azure Subscription but according to…

… it suggests that the Account ID (which is just the Azure subscription name prepended with ‘azureserviceprincipal-’ yes?) should be used.

At any rate, either doesn’t work… so I suspect that Octopus is doing some initial validation of which Azure subscription to use before running any steps, but cannot as the step has not yet run!

Is this correct and this is an unsupported scenario? Or am I doing it wrong?

Hi James,

Thanks for getting in touch.

We’ve reproduced this and can confirm this is a bug. You should be able to use output variables in these account fields, so we’ve created a GitHub issue here that you can follow to be notified when a fix is available.

In the meantime, you could potentially work around this issue by creating multiple/duplicate steps for each account/azure-subscription, then use Channels to ensure you only deploy to a given subscription at any one time. For example, have a Subscription1 and a Subscription2 channel, and scope the steps to the channels accordingly, then deploy to the given channel (depending on which subscription you currently have active).

Hope this helps.


Thanks for the feedback.

In my case I’ve decided to stop penny pinching from developer’s MSDN subscription Azure benefits - and just create a separate dev/test account for the test environments! But it seems like something that should work, so good to know it has been confirmed as a bug.