Is there a documented order of precedence for variable definitions overriding other definitions?
We’ve observed a case where a variable scoped to a certain environment seems to take precedence over a variable with the same name scoped to a specific step number. But we’ve also seen non-deterministic behavior where it seems like precedence may not be formally enforced at all and the last match wins (or first match?).
I would expect the order of precedence to be:
I’m not really sure about step and machine. Which is more specific?
Anyway, we’re trying to avoid overriding variables with different scopes since we can’t figure this out.
As you say, the order should be:
- No Scope
Basically, variables are “scored” in the same way CSS settings are, with the following weightings:
- Step matches: 1,000,000 points
- Machine matches: 1,000 points
- Environment matches: 1 point
So for example, the precedence of the following variables would be:
- Step 1, Machine 1, Env 1 - score 1,001,001
- Step 1, Machine 1 - score 1,001,000
- Step 1, Env 1 - score 1,000,001
- Machine 1, Env 1 - score 1,001
- Machine 1 - score: 1000
- Env 1 - score: 1
Hope that makes sense. I have a test to check that this currently works, but if you see the wrong variable being selected please let me know.
Can you tell us how project variables and shared variable set variables are weighted? Essentially, If I have a variable in my project, will it override a variable in a variable set with the same name?
Thanks for reaching out. Paul wrote a blog post where he attempted to explain the “Variable Weight” in more detail: https://octopus.com/blog/variable-specificity-and-complexity
If you have a Variable in your project (PV) with the same name as a variable in a variable set (VSV) and both variables are not scoped to anything, then PV will win as it is more “specific” than VSV (Projects are more specific than Variable Sets because Variable Sets can be used by any Project).
If you scope VSV to lets say a specific target, and you leave PV unscoped, then VSV will prevail, as it’ll is more specific than the unscoped project variable.
I recommend you to read Paul’s blog post to get a better understanding of the variable’s weight and the logic we followed when we developed it.