Tenanted bound variables for azure accounts not working

[dingus]

Octo version: 2020.5.0

I have the need to select an azure account based on environment and tenant from an azure powershell step. I’ve actually had this same issue in the Terraform steps.

I have the following

Accounts:

• Account-Dev-UK
• Account-Dev-USA
• Account-Prod-UK
• Account-Prod-USA

Tenants:

• UK
• USA

Environments:

• Dev
• Prod

Library Set:

• Azure Environment Accounts
  • Tenant common variable/library set template variable (side note: can we get the naming in sync on these?):
    • AzureEnvironmentAccount (Type=Azure account OR single line text box, neither work)
  • library set variables:
    • AzureEnvironmentAccount.UK
      • value scoped to dev environment - Account-Dev-UK
      • value scoped to dev environment - Account-Prod-UK
    • AzureEnvironmentAccount.USA
      • value scoped to dev environment - Account-Dev-USA
      • value scoped to dev environment - Account-Prod-USA

The tenants then have the AzureEnvironmentAccount template variable set to the appropriate UK or USA library set variable as an octo var binding.

This should allow me to just use the tenant common variable/library set template variable in my azure powershell step but I receive the following error.

It is the correct ID and the account exists but I believe it is the binding that is causing the issue rather than the template var being directly set as an azure account type.

[paul.calvert]

Hi @dingus,

Thanks for getting in touch!

I’ve created a test of this and haven’t encountered the same problem. This is what I’ve configured if you can review and let me know if I missed anything:

Library Variable Set Template:

Tenant Variable:

Process Step:

One thing that would be worth checking, is your Azure account is also linked to these tenants?
e.g.

Regards,
Paul

[dingus]

Hi Paul,

Thanks for replying so soon. Your example is just missing a few bits.
You’ve got the template variable but could you now create a library set variable(not template), lets call it “AzureEnvironmentAccount.UK” and have that set to your azure account.

Then, when setting the value in the tenant make sure you are binding to that new var rather than referencing the account directly. So use #{AzureEnvironmentAccount.UK}.

And you already have the correct binding in the powershell step.

Thanks.

[paul.calvert]

Ah ok, I understand now.

Unfortunately, I have worked on this process of nesting an account variable within another variable before and the only way to get this to work was to add the Azure account directly in the Tenant variable.
Which, to get the environment scoping that you need will mean using a Project Variable Template rather than the Library Variable Template.

Am I correct in thinking the use case here is as simple as:
“Have an environment scoped Azure account apply to a Tenant across multiple Projects without having to configure it in every single Project”

[dingus]

Yep you’ve nailed it on the head.

We have an azure subscription per environment per tenant. So in the example I gave at the beginning we have 2 environments(dev & prod) and 2 tenants(UK & USA) = 4 subscription which means 4 octo accounts. As you can imagine we have replicated apps across all of these, each of which is configured for octo deployment and I’d like not to have to configure it repeatedly for each project.

I found similar github tickets open but nothing that quite matched this issue. Could you open one for me?

[paul.calvert]

That make sense.

I’m raising it internally but at this point it seems to be a bit of a grey area between an issue and a feature request because I don’t believe this has ever worked in the way that you need.

I will update you further once I have a response from our engineers.

[dingus]

I would hope it would be raised as an issue as I cant find a mention of Azure Accounts variable type binding being treated differently to other types in either of these docs:

Variable substitutions - Octopus Deploy

Azure account variables - Octopus Deploy

But I appreciate you raising that for me.

[paul.calvert]

Hi @dingus,

Our engineers have been looking into this and have found that setting the variable type to single line text box in the library variable template does prevent this error from occurring.
e.g.

I’ve tested this and it is working for me also.
Would you be able to give this a try and see if it resolves the problem for you?

Regards,
Paul

[dingus]

Hi Paul,

How strange, that does seem to work. In my original post I mentioned that I had tried that before. Anyway I’m happy that it’s now working.

Thanks for looking into it for me. Much appreciated.