Due to our use of multiple tenants/environments, we have a scenario where we need to bind a variable to get the ID of an AWS account to use. However, upon deployment an error message is displayed.
Could not find account with ID ‘b9efe724-33fd-4681-9bbd-2be2cf5f0f8c’, which is the value of variable ‘Account’. Perhaps the account has been deleted?
Full details
We have a library variable set containing variables for a tenant. In this case, there is an AWS account variable called Test.AwsAccount that has a different account scoped for each environment.
We also have a tenant that contains a tenant common variable called AwsAccount. The value of this is bound to Test.AwsAccount, thus allowing us to have environment specific variables for all projects in the tenant.
Finally, in the project process there is a AWS CLI script step, and from the “AWS account variable” dropdown we select AwsAccount.
Now when we create a release and attempt to deploy it the above error message is displayed.
Note that ‘b9efe724-33fd-4681-9bbd-2be2cf5f0f8c’ is the ID of the common variable AwsAccount, and is not the value of any variable (I believe this message is probably UI bug). Looking at the API, it shows that the value is #{Test.Account}, as expected.
The variable preview shows that the binding has worked as expected, however it seems like the binding isn’t working when a release is being deployed?
If so, then you might try either removing the scoping or specifying your environments there.
If that doesn’t change anything, then I was wondering what happens if you attempt to set the Test.AwsAccount variable type to single line text box instead? I’ve seen this work for other similar cases, and I was wondering if it might work for your case as well.
The account is scoped to the appropriate environments and tenants. Also we have tried to set the tenant variable defined in the variable template to a single line text box and the exact same error is displayed.
We’ve found a work around for this, and that work around is tenant tags.
The difficulty we’d been having was scoping tenant common variables per environment, and this led to us having to have a library set for each tenant as well as the tenant common variables which bind to the relevant library set (as described in the OP).
We were unaware that you could scope variables in a library set to tenant tags, as it’s not at all obvious through the UI. When selecting the ‘Scope’ column, the visible dropdowns only show environments, roles and targets.
However, when you click ‘OPEN EDITOR’ an additional dropdown for our new tenant tag set is shown.
So now we’re going to remove tenant common variables, because honestly they are not fit for purpose, and just stick with the library sets and tenant tag scoping.
Thanks for getting back to me and letting me know.
I’m glad to hear you were able to find a workaround for your use case, and that’s helpful to know the UI is confusing around scoping variables to tenant tags. If you get a chance, adding this feedback to our UserVoice would be valuable for us: https://octopusdeploy.uservoice.com/
Let us know if you have any other questions and we’ll be happy to help!
