Prompt variables not updated using scoping rules

Hi. I’m using Octopus 2019.6.0.

I have found that if a default value is set for a “prompt for value” for a variable, and then add a duplicate variable or additional value is added which should take precedence according to scoping rules, the latter is ignored in deployments and the default value from the prompt variable is taken.

examples seen so far:

  • ‘Prompt for value’ for environment X with default of ‘true’ and non-prompt of “False” for environment Y leads to working value of “True” in environment Y
  • Prompt for value in library variable set with default value of ‘true’ and non-prompt of “False” (to override) for a specific project which uses the library set, leads to working value of “True” for the project.

Haven’t checked to see if the behaviour is the same if the override value is also a prompt variable, but really it shouldn’t matter. The user might, in general, want to prompt, but if they decide for a specific situation to always use the same but different value, then they are stuck with original default

Cheers

Steve Marsh

Hi Steve,

Thanks for getting in touch! I’m sorry to hear you’re hitting this unexpected issue. The way I understand what you’ve described definitely seems like the incorrect behavior here. You’re correct in that which variable value is used should only be determined by its scoping, and not by the fact that one value is prompted and the other isn’t. The only exception is if you have two matching variables with matching scopes, but one is defined in the project and the other in a library variable set, the project variable will get precedence.

I’ve run through a simple test (in 2019.6.0 as well), where one variable has two values, the first value being scoped to Development, and is prompted with a default value, and the other scoped to Test which is just a standard, non-prompted variable with a different value. When I deploy to each environment, the correct value is used based on their scoping. So I haven’t been able to replicate this same behavior, and we may need some additional information to help me replicate your scenario more accurately.

Can you provide screenshots of these variable values (showing where they’re set, and how they’re scoped)?
Can you send us a full verbose task log from a deployment getting the wrong value? The following doc page outlines how to produce and export this verbose log with debugging variables enabled.

I look forward to hearing back and getting to the bottom of this one!

Best regards,

Kenny

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