We’re migrating from one naming convention to another, and creating parallel sets of variables - changing from system.component.some_config_setting to System.Component.SomeConfigSetting
Whilst doing this, I noticed that Octopus will allow me to create two variables that differ only in case - so I now have system.component.foobar and System.Component.FooBar defined as variables in the same library variable set.
How does Octopus handle this when deciding which value to replace in a config file?
(Out of interest, I checked how .NET handles this - e.g. using this configuration:
ConfigurationManager.AppSettings["someconfigvalue"] returns "lowercase", but ConfigurationManager.AppSettings["SOMECONFIGVALUE"] ALSO returns "lowercase" - i.e. you can define the same key multiple times and it looks like the last value wins…
Not entirely sure exactly what the ‘right’ answer is here, but I’d appreciate knowing how Octopus deals with this when matching and replacing variables.
Thanks for reaching out. Let me help you put some light into this.
Variable Names are not case sensitive. You can create as many as you want with the exact same name.
Variable contents are not case sensitive by default, but the can be configured to be case sensitive
When you have 2 variables with the same name and same scope, It’ll be hard to tell which value will prevail. You must avoid this scenario as it will only lead to erratic behaviors.
When you have 2 variables with the same name and Different scope (which is a practice we recommend), the value that will prevail will depend on the step/machine/environment where the value. The trick is being smart with your scopes.
Thanks for such a detailed response – we’re using scopes exactly as described, so this is working fine. Whilst it’s not a bug per se, it would make things much clearer if Octopus would warn you if you did create two variables with the same scope whose names differ only by case – might this be a feature you’d consider for a future release?