CODEWITHSUNDEEP
azure-devopsyamlazure-pipelines
derekantrican
derekantrican

Reputation: 2285

Pipeline parameter overwrites variable value

I have a pipeline in Azure DevOps somewhat like this:

parameters:
- name: Scenario
  displayName: Scenario suite
  type: string
  default: 'Default'

variables:
  Scenario: ${{ parameters.Scenario }}

...
    steps:
    - script: echo Scenario is $(Scenario)

And I'm executing the pipeline via the VSTS CLI like this:

vsts build queue ... --variables Scenario=Test

When I run my pipeline, it seems that the parameter default value overwrites my cmd line specified variable value and I get the step output Scenario is Default. I tried something like Scenario: $[coalesce(variables['Scenario'], ${{ parameters.Scenario }})] but I think I got the syntax wrong because that caused a parsing issue.

What would be the best way to only use the parameter value if the Scenario variable has not already been set?

Upvotes: 0

Views: 2524

Answers (2)

derekantrican
derekantrican

Reputation: 2285

Lance had a great suggestion, but here is how I ended up solving it:

- name: Scenario
  displayName: Scenario suite
  type: string
  default: 'Default'

variables:
  ScenarioFinal: $[coalesce(variables['Scenario'], '${{ parameters.Scenario }}')]

...
    steps:
    - script: echo Scenario is $(ScenarioFinal)

In this case we use the coalesce expression to assign the value of a new variable, ScenarioFinal. This way we can still use --variables Scenario=Test via the CLI or use the parameter via the pipeline UI. coalesce will take the first non-null value and effectively "reorder" the precedence Lance linked to here: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch#expansion-of-variables

(Note that there need to be single quotes around the parameter reference '${{}}' because the ${{}} is simply converted to to the value, but then the coalesce expression doesn't know how to interpret the raw value unless it has the single quotes around it to denote it as a string)

Note that the ability to set parameters via the CLI is a current feature suggestion here: https://github.com/Azure/azure-devops-cli-extension/issues/972

Upvotes: 1

LoLance
LoLance

Reputation: 28196

What would be the best way to only use the parameter value if the Scenario variable has not already been set?

Sorry but as I know your scenario is not supported by design. The Note here has stated that:

When you set a variable in the YAML file, don't define it in the web editor as settable at queue time. You can't currently change variables that are set in the YAML file at queue time. If you need a variable to be settable at queue time, don't set it in the YAML file.

The --variables switch in command can only be used to overwrite the variables which are marked as Settable at queue time. Since yaml pipeline doesn't support Settable variables by design, your --variables Scenario=Test won't actually be passed when queuing the yaml pipeline.

Here're my several tests to prove that:

1.Yaml pipeline which doesn't support Settable variable at Queue time:

pool:
  vmImage: 'windows-latest'

variables:
  Scenario: Test

steps:
- script: echo Scenario is $(Scenario)

I ran the command vsts build queue ... --variables Scenario=Test123, the pipeline run started but the output log would always be Scenario is Test instead of expected Scenario is Test123. It proves that it's not Pipeline parameter overwrites variable value, instead the --variables Scenario=xxx doesn't get passed cause yaml pipeline doesn't support Settable variables.

2.Create Classic UI build pipeline with pipeline variable Scenario:

enter image description here

Queuing it via command az pipelines build queue ... --variables Scenario=Test12345(It has the same function like vsts build queue ... --variables Scenario=Test) only gives this error:

Could not queue the build because there were validation errors or warnings.

3.Then enable the Settable at queue time option of this variable:

enter image description here

Run the same command again and now it works to queue the build. Also it succeeds to overwrite the original pipeline variable with the new value set in command-line.

You can do similar tests like what I did to figure out the cause of the behavior you met.

In addition: VSTS CLI has been deprecated and replaced by Azure CLI with the Azure DevOps extension for a long time. So now it's more recommend to use az pipelines build queue instead.

Upvotes: 1

Related Questions