We are getting the following error when trying to promote a cloudformation template step:
It’s working for the first environment, but promoting to the second is giving this error. We have a library set with our AwsAccount variable attached to the project. It looks like this:
We don’t understand why the scoping is not working here as it works on everything else. We are using 2019.6.1
To add more context, our lifecycle has two phases: non-prod and prod. Non-prod goes to PropSol - AWS - NonProd and prod goes to PropSol - AWS - Prod. Not complicated. We’ve also tried creating a binding variable and separating the AWS accounts into two variables, but that still had the same issue.
Hi @Chris_Robison,
Thanks for the question about scoping accounts and variables, and apologies that the information on screen isn’t proving to be helpful in understanding what is going on.
In your case it is probably because the Refs-Octopus-NonProd account itself has a Restriction on another environment, and when we try to promote the deployment to production the AwsAccount variable, having been ‘unscoped’ on environment (implying it can be used in all environments) we need to check to see if Refs-Octopus-NonProd is allowed to be used there.
I can replicate your behaviour by setting up the following scenario. First create an Account with a Restriction on the dev environment, I create a second account with a restriction on the prod environment.
Then I recreated your project variables in the same way you described.
The deployment to Development environment works because the environment restriction check survives. But in Production it fails, because aws-test-account is explicitly restricted to Development only, while being referenced by a variable value that is available in all environments (‘unscoped’)
In general aligning the variable scoping with the Account restriction should work. In practice the fix depends on what you want to do. I suspect you want to apply further scoping to the variable like this, so that it is only ever used in that environment.
The other approach would be to relax the restriction on the Account itself, however this doesn’t look like it fits your scenario.
I hope this helps? Please let me know if you feel there is an approach we could take to make this clearer.
All the best,
Well, you’ve done a great job guessing our setup. Sorry for not providing enough context. We do have environment restrictions on each aws account like you have. And we also do have no restrictions on that one variable as we want to it be the default for everything expect production. It’s our understanding that variables are resolved based on specificity and we’ve setup lots of variables this way (having a default with no restrictions and only adding more specific vars for environments that need it) and it seems to be working. What makes AWS account variables different in this case? Why does going to production in this example fail because of the unscoped variable when it should be choosing the more specific one?
Thanks Chris,
No problem, you were following a pretty standard pattern there so it all made sense and felt familiar to me, also the error message is quite specific so tracking it down in our code revealed a lot. Thanks for all the good details!
We think you are 100% correct too, this feels like a bug when it comes to variable specificity, so I’ve lodged an issue for you to track here. While lodging that issue I discovered that we’ve also encountered this same issue with Certificate variables too. I’ve linked that older issue to our newer one.
The workaround I described above should get you out of hot water, but it doesn’t scale very nicely, and the current behaviour feels very inconsistent.
The AWS account (and other types of Account variables) is different because it has an additional ‘layer’ of scoping. It fails in production because our check against this layer isn’t taking into specificity into consideration, its a bit too simplistic, in that it is checking every variable value, rather than the most specific one.
Please let me know if I can help further working around this issue while we move to address it.
Best,
We’ve matched all the scopes up between the variable and the AWS account and everything is working again. Thanks for your help.
