Octopus Variables - Environment targeting vs Environment and role

Legacy Execution
1

Hello

I’m seeing what i believe to be the incorrect behavior when determining what variable to be applied for a particular environment.
To help understand my issue I will detail what i have setup first.

I have a variable set with the following variables
Username = User1, Environment = Test
Username = User2, Environment = Test, Role = RoleA

My step in Octopus is to install a windows service. The Environment is it targeting is Test and the role is RoleB. So I would expect the username applied to be User1, however I am having User2 being applied.

To test further, i then set a project level variable of Username = User1, Environment = Test, however this still ended up as User2.
Just to confirm, when i changed anything regarding variables I updated the variables in the release. I also tried creating a new release.

The only workaround ive got a the moment is to create a project variable of Username = User1, Environment = Test, Role = RoleB.

I feel having a variable applied when its targeting the wrong role is bug, hence raising this. My version of Octopus is 3.12.4

Please let me know if you need further information.

Mark

2

Hi Mark,

Thanks for getting in touch! Unfortunately the behaviour you are seeing is, if not directly by design, a known limitation when it comes to scoping.
We have some documents that explain precedence and specificity to which I have linked below.

The tl;dr; is that the environment scoping is matched for both variables when any machine from Test is deployed to. Because there is no further specificity for those machines, either variable has the same weight. There is no negative weight for additional non-matched scopes on a variable, and it isn’t a full match of: only this role in this environment.

https://octopus.com/docs/deploying-applications/variables/scoping-variables#Scopingvariables-Scopespecificity

Sorry if that isn’t the information you were hoping for.
Vanessa

3

Hi Vanessa

Just to make sure I’m completely clear.

My variable is getting targeted with environment and role, however the role is not the role my step is setup for.

So ultimately if my variables in a library set are

Username = user1
Environment = Test

Username = user2
Environment = Test
Role = RoleA

Then my step is referencing the Username variable and the step is running in the Test Environment but under the role RoleE why does it get the variable assigned for RoleA. I think Username should be “user1” however its getting “user2”

This feels like a bug and not a limitation. It’s targeting against the wrong role

Regards

Mark

4

Hello, is there any update this to this yet?

Thanks

Mark

5

Hi Mark,

Sorry for the delay. We’ll try and explain in more detail as to why we take this stance.

In this case, Octopus is targeting the wrong role because it is conflicted over a choice between two variables that it considers to have the same weight. As described earlier, this is a known limitation of our variable scoping with multiple values.

Considering your variable set:

Username = User1, Environment = Test
Username = User2, Environment = Test, Role = RoleA

As shown in the Rank() method from the variable specificity and complexity blog post, when calculating which variable to use when targeting your Test environment and your RoleB role, there is no negative weight applied for additional non-matched scopes on a variable (non-matched scopes in this case = RoleB). Octopus would consider this to be the same weight as if it were just targeting the Test environment, because you have not defined anything more specific for it to match on, when provided with the RoleB role.

Therefore this case is forcing Octopus to choose from two variables it considers to have the same weight, and it happens to choose what you consider to be the wrong one.

As the documentation on scope specificity states, you need to take care when scoping variables so that they are unlikely to conflict.

To be clear, this is not something we consider a bug, but a known limitation where the workaround is to ensure you have defined specific-enough variable scoping to avoid conflicts such as these. If you add a more specific scoping as follows:

Username = User1, Environment = Test
Username = User1, Environment = Test, Role = RoleB
Username = User2, Environment = Test, Role = RoleA

Octopus will then have a clear single choice based on the Rank() calculation.

Further down in the same blog post describes a similar situation using roles as an example regarding a DatabaseName variable. This post can help to better understand our perspective.

Hope this helps.

Cheers
Mark