Hi, I am running Octopus 3.2.24 and we have appSettings which use the same key between our backend app and frontend website. I have created a variable in Octopus, scoped it to one environment and to my role for the website but the value is applying to the app also.
If I check the verbose log, I can see it says “Setting ‘PS3.Dal.Timeouts.Default’ = ‘60’” but this step is to run only on targets PF-AppServer where as the variable is scoped to the one environment and to only the PF-WebServer role.
Is this a bug or by design that variables don’t scope this way?
Screenshots attached
Thanks
Gavin
Hi Gavin,
Thank you for reaching out! Firstly, please let me know if I’m wrong about your setup (I’m assuming your PF-AppServer machine is also in the Demo environment). Since the variable is scoped to both the environment and the role, the other machine (that doesn’t have that role) in that environment is considering the variable as scoping to itself as well. Scoping will determine which machines the variable will apply to, and if its scoped to both an environment and a role, it will apply to any machines in that environment, or any machines with that role, but not only machines with that role in that environment.
The best way to resolve this would be to remove the scope to your demo environment, and leave only the scope to the role.
For troubleshooting purposes, there is a great way outlined in our documentation to see all of the variables being used in a deployment. By turning on two special variables, it’ll print out the variables used, and the values after evaluating for deployment.
I hope that helps!
Kenny
Hi Kenny
Your assumption is correct, there is only one machine in the demo environment which is tagged with PF-AppServer, PF-SQLServer and PF-WebServer roles.
I guess I’ll have to put another tentacle on the machine to get around the issue as I cannot remove the demo environment scope else all the other sites that get deployed to will get this value incorrectly.
Regards
Gavin
Hi Gavin,
Adding another Tentacle with another role, and scoping the variable to that new role sounds like a great solution. Another option may be to scope the variable to the step itself, instead of the role.
Let me know how you go!
Kenny
Ooh didn’t think of the step part, maybe I should look longer at the create variable screen next time (just noticed the prompt option after all this time!)
I’ll scope it just to the step and the environment then thanks!
