Thanks for getting in touch! I had a discussion with my team regarding your question, and what we think may be a good solution is to use a variable set. You can include this single set into each project that requires it. This may be easier to manage, and your URIs will evaluate as expected.
As an example, I've set up these environment variables in a new variable set, scoping them accordingly to each environment. I've left the value of the variable scoped to production empty.
The first screenshot shows the variables in the set.
The second shows the evaluated variables in my Development environment.
The third shows the evaluated variables in my Production environment.
Does this look like an easier to manage setup?
Let me know what you think, how you go and if you have any further questions at all.
Thanks for getting in touch. A seperate variable set is not the desired answer ;) How you suggest it, we're doing that exactly.
But, we have over 60 projects in octopus. Most of them are applications that call other applications. In a common project we refer to multiple variable sets. Like eg. web-services or external-services. In these variable sets we already declare such an environment variable. But we're declaring it in every variable set. That doesn't feel good. A variable set inheriting other variable sets would do the trick but that's not possible in Octopus right now. Creating custom system variables, which are always available, like the octopus system variables. Seems like the best fit.
From my perspective an editable Octopus System Variable or inherited variable sets would be great. Maybe we've structured/designed our octopus projects in a bad way.
Thanks for following up! I'm sorry if I've misunderstood initially, and please correct me again if needed. :)
You're correct that it's not possible in Octopus for a variable set to inherit another set, unfortunately. Just to confirm I understand your current setup, are you defining the exact same URI variable/value/scope in multiple variable sets?
If this is the case, and since many projects can use a single variable set, I was suggesting splitting all of these common variables (those that are used in every project) into a single variable set to create just a single place to manage them. However, you would need to include this into each project that needs them as well. You would be able to just include this set when you create a new project, so you won't have to define each of these variables again.
Some interesting news, you can overwrite a system variable by defining a new variable in a project or a set. For this environment variable example, you could create a new variable named Octopus.Environment.Name (same as the system variable name) and it'll evaluate to this new value. This is the only way to do it, though, so probably not of much help here. Otherwise, you'd need to change the name of the actual environment itself to change the overall system variable value.
Additionally, the ideas to allow variable sets to inherit other sets, and to customize system variables may be great ideas to suggest on our UserVoice site. We use UserVoice as the main source when considering new features and enhancements like these. https://octopusdeploy.uservoice.com/
Let me know if this helps. Feel free to expand a bit on your current setup with screenshots or any other relevant info if needed, and I'll be more than happy to help you try to find the best solution for your specific case.