Thanks for getting in touch. So glad you asked the question.
In general, Common variables are meant to be used for values that are consistent across projects and environments for a specific tenant. They serve as a custom field of sorts for your tenants.
Can you provide me with more detail and context on what type of values you are managing with Tenant Common Variables? There might be a way around this limitation or possibly another way to handle these Environmental value changes that will work just as well.
Looking forward to hearing from you shortly.
The solution Ryan is proposing is interesting and doable. But for me it is more a workaround and not a real solution.
There is a main drawback which mainly come out in complex setups as our one where we have many common variables. In our case we would be obliged to use API in order to generate the templates Ryan proposes.
Moreover our product evolve continuously and every time we add a new common variable then we have to create the environments template. Moreover if we add a new environment then we have to update all templates which can be many !
So that workaround can be source of errors and can be very time consuming for complex setups.
For us is then much more simple to duplicate tenants and postfix tenants with the acronym of the environment, e.g.:CUSTOMER1_ QA, CUSTOMER2_ QA, CUSTOMER1_PROD, CUSTOMER2_PROD.
Personally I consider simpler and more natural to add an additional dimension “environment” to the template common variables, as it is for project variables
OCTOPUS is a great and powerful CD solution. To have Template Common Variables scoped to environment as it for Template Projects Variables would make OCTOPUS better and more powerful. I hope Octopus’ team considers to implement this functionality soon !