Previously, we were using Octopus environments only to scope our Azure accounts and it worked just fine.
Now, I am trying to use tenant tags to scope the Azure account variables, but Octopus is unable to resolve the variable name to an Azure account.
The variable that it should find is in Project Variables, scoped to a single tenant tag from a tenant tag set. The Dev tenant I’m trying to deploy to has that tag. Under accounts, the relevant Azure account is scoped using both the environment that Dev tenant belongs to and other environments, and a tenant tag from the tenant tag set. It is the same tenant tag that the Dev tenant has and that the variable in project variables is scoped to.
This appears to be a bug in Octopus variable scoping related to tenants & accounts. Can you confirm?
Since I really need to do a deploy ASAP, I changed all our Azure accounts (in Environments/Accounts) back to using the environment only, and not any tenant tags for scoping. Then I changed the AzureAccount variables back to using environment.
I created a new releases after all changes had been made, and it still failed to resolve the AzureAccount variable with the same error as pictured above. It appears my previous state was cached somehow? I created a second release to ensure that all changes were included. It still failed in the same way.
I know the Dev tenant belongs to the Dev environment. Environment = Dev is the only scope used by the AzureAccount variable in Project Variables and the matching Azure account under Environments/Accounts.
Thanks for getting in touch. We have been able to confirm that there is an issue with resolving an Azure account when a tag is being used to scope the project variable. I have created an issue, which you can track on GitHub, and we’re currently looking at a fix.
I initially had difficulty reproducing the issue because I wasn’t using a Cloud region, I was only using the tags and not setting an “on behalf of” role for the deployment step, and in that scenario the variable resolved correctly. You may be able to use this as a workaround in the short term until we can get the fix shipped. So you’re aware, I did find a secondary issue with that scenario, as detailed here, where if the variable resolves then the account will always be used, even if it has tags that mean that tenant shouldn’t actually have access to it. This won’t block deployments, but could use an account when it shouldn’t if you get the configuration wrong.
I hope that helps and apologies for the inconvenience caused. You can track those issues on GitHub to see when they get released and if I can be of further assistance just let me know.
We’re not actually using cloud regions at all. We are running the Azure step “on behalf of target roles”, but in that field we have a normal role tag used by our polling tentacles. The polling tentacles with that role tag are the ones associated with the tenant and that have the tenant tag we want to use to determine which Azure account variable to use. The Octopus server does not have that tenant tag nor does it belong to any tenants.
Yes, that will be the same scenario. The issue relates to the resolution of the variables based on the tenant (the tenant’s tags weren’t being passed to the filter correctly) and will occur if there is an “on behalf of target roles” role specified (whether the target be a Cloud region or a polling tentacle). When there is no “on behalf of target roles” the step is referred to as Server Side and the validation is different, which is how it is able to resolve the variable but also the source of the secondary issue I mentioned.
I have a fix for the primary issue, which is being reviewed at the moment. Will hopefully be in our next patch release.
