Scoped Prompted Variables always using the "default"

[peter.weston (Pete Weston)]

Afternoon,

I have recently had tickets raised from our Live deployment people stating that their prompted variables are not the answers they were expecting.

When I look at the setup we have a prompted variable with a value and no scope, in this instance set to “false”, then a second value, not prompted and a value of “true”, but scoped to an Environment. This would be production, but in the test example screens below, our scope will be “charlie”.

When choosing to deploy to the Bravo environment, the prompt displays as “false” as expected:

When choosing to deploy to the Charlie environment, the prompt displays as “false”, however we were expecting it to be “true”:

If I make both variable values to be prompted, I see two checkboxes when coming to deploy (was not expecting to see two), and I get one “false”, and one as “true”! Although having both shown to the user would be confusing, so doubt this is an acceptable solution:

I have searched the forum and read this article:

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 env…

Which indicates it should be reading the variable scopes correctly, however due to my testing of one variable, it feels like I would need to find all of our Prompted Variables and we would have to scope all of the “defaults” to be all the ‘other’ environments. Which will be one hell of a task!

Is this expected functionality? I am certain this used to work and I’m wondering if something has been changed?

I updated us to be using the latest version yesterday (Octopus.2023.2.13151-x64), just in case it was a version thing, but it has not resolved the issue.

Thanks for any help or things to try

[paul.calvert]

Hi @peter.weston,

Thanks for getting in touch!

With the variables configured in this way, I would expect the Checkbox prompt always to appear, regardless of which environment you are deploying to.

However, when deploying to the Charlie environment, the variable defined will overwrite the prompted checkbox.
e.g.
Variables:

Checkbox unticked (so value false)

Value output as true due to the scoped value being more specific than the unscoped one

There are essentially two different checks occurring at slightly different points.

On the initial “Deploy Release” page:
Is there a prompted variable that applies to this environment? If yes, show the checkbox - The unscoped value means this is always yes.

Once the Deployment executes:
What is the most specific value to use for this variable - When deploying to environment Charlie, this will force the value to be true regardless of the checkbox response

Regards,
Paul

[peter.weston (Pete Weston)]

Thanks for the quick response Paul.

So what we are saying is that even though the user can see the checkbox, and its value is “false”, if they ignore it and click deploy it will actually be “true” when doing the deployment to the Charlie environment, because it has a scoped value?

I cannot see our production deployment team being happy that they can see the value on the deployment, but it’s then different to what they have seen. Currently they go and tick the checkbox to make it “true”, if I am reading your response correctly, that action is pointless as it would be overridden anyway?

Sorry, but in that case, why have prompted variables at all if the user interacting with them does nothing if there is an underlying scope? Surely the reason we prompt the user is to give them the choice (especially in our internal QA deployments) so they can decide at deployment time, and not due to the variables being correct.

I will have to investigate all of our projects and revisit the initial setup if that is the case.

[paul.calvert]

That’s correct.

In this scenario, the only reason I could see to have the scoped value is to protect against user error at deployment time.

Let’s say you have environments Dev, QA, UAT, Prod.
You’re OK with the user managing the checkbox at deployment time for Dev, QA, and UAT, but you know that deploying without the checkbox in Prod would cause a problem, so you scope the value to true for Prod. That way, no matter what the user does when deploying to Prod, you are confident the correct value is used.

I do agree that it can appear confusing to show the checkbox when it isn’t being used, but unfortunately, that is a side-effect of defining the variables in this way. As you mentioned earlier, scoping the prompted variable to the specific environments you want it to be used in would fix this but I appreciate that could be time-consuming if there are many projects and environments to consider.

[peter.weston (Pete Weston)]

Thanks for clarifying Paul, appreciate it.

As long as I know, I can raise it and see how we take this forward.

Have a great weekend.