Override prompted variables from library set

I have a library set containing several variables that prompts for the value at deploy time using checkboxes. In some cases, one or more of these variables are not relevant to the consuming project, so I hoped that I could simply override it by having a variable for the project with the same name and scope and then this would override the one from the variable set. However, the checkbox is still visible. I’ve tried some variations of scoping to try to give it more specificity"but with no luck.

Based on the answer here, I guess that the behaviour I am seeing is a bug. Could this be fixed, please?

Hi Kristian,

Thanks for getting in touch!

I’ll do some testing on this but it does sound like it is working as intended.
The variable comparison between library and project variables is done based on the values, not the variable itself. So, project variable values take priority, but the project variable doesn’t completely replace the library variable.
So, when you deploy your scenario, the library variable still exists so it has to prompt for the tick box. After that point though, if anything tried to use that variable, it would receive the value you’ve set at the project level rather than the tick box value.

To exclude these checkbox variables from specific projects the best solution would be to split them off into a separate Library Variable set which you can then only link with the projects that require it.

Regards,
Paul

Ok. But isn’t that behaviour a little confusing and unnecessary?

So, when you deploy your scenario, the library variable still exists so it has to prompt for the tick box. After that point though, if anything tried to use that variable, it would receive the value you’ve set at the project level rather than the tick box value.

This means that the UI renders an useless checkbox, since the value of it will not be used for anything anyway. In my opinion, the better behaviour then would be to simply not render the checkbox at all.

Whilst that is correct for your specific scenario, there are other scenarios that need to be supported which require it to work the way it does.

e.g.
Variable A exists in the library set as a prompt variable.
Variable A also exists as a project variable with a static value. This value is also scoped to a specific deployment target.

On the deploy screen, you have not yet committed to Octopus which deployment targets are going to be used, therefore it needs to prompt for the library variable value even though it may not get used.
Once the deployment actually starts, Octopus then has all of the necessary information to determine which variable values it needs to use and where.

Ah - I didn’t think of that. Then it makes a little more sense.

Would it be possible (and this is just a shot in the dark) for the UI to be more reactive to the users choices? In your scenario, the library variable would need to be promted for anyways since the project one is scoped more narrowly. However, if it was the other way around, it would be a neat feature if the Octopus UI could show the prompt if and only if it does indeed have a purpose.

I understand perfectly fine if it is too much to ask, as I think most people use the scoping features of Octopus a lot more than we do. We mostly only scope on environment and use other means to differentiate targets.

I’ll will raise this with our product team to review and see if it is something that we could add.

I have a feeling that adding this kind of logic to the deployment screen would potentially create a performance hit for customers with an extreme number of variables though.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.