Azure Devops Pipeline with Manual Run and User-Set Variables: How to check variables in conditions?

Question

Hoping someone can help me with this as looking back at my git log I've now tried 14 different things to try to get this to work. Here's the scenario:

I created a variable in the UI called deploy_custom_env and checked "User can set variable at runtime." I initialized it to "default", but I am expecting users to override it when starting manual runs.
I am trying to use this variable in the condition for some of my pipeline stages.
I've tried many, many different things. Here are some examples:

First:

condition: ne(variables.deploy_custom_env, 'default')

And

condition: ne('${{ variables.deploy_custom_env }}', 'default')

And

variables:
- name: isCustomEnv
  value: ne[($(deploy_custom_env), 'default')]

And even

variables:
  - name: isCustomEnv
    value: ne[(variables.deploy_custom_env, 'default')]

Hilariously, when trying to use the above, both of the following conditions result in skipped stages:

condition: eq(variables.isCustomEnv, true)
condition: eq(variables.isCustomEnv, false)

Does this mean it's both true and false? (I'm kidding, of course: I have no clue what this actually evaluates to.) I've also tried enabling System.debug and checking "Enable system diagnostics"`, but when my stages get skipped, I can't really see what these variables are evaluating to.

I would appreciate any suggestions or documentation that will help me solve this problem. Surely this is something that people do? Also, recommendation for anyone from Azure reading: I would love to see this example in the documentation somewhere.

I looked at the following to try to answer this:

In the latter, I saw the difference between compile-time and runtime, with the following note:

The difference between runtime and compile time expression syntaxes is primarily what context is available. In a compile-time expression (${{ }}), you have access to parameters and statically defined variables. In a runtime expression ($[ ]), you have access to more variables but no parameters.

That seems related, but how do I translate this into something that works in my conditions?

WaitingForGuacamole · Accepted Answer · 2021-03-05T20:03:28.117

I'll give you one more variable syntax to try, and then another way to do it

This syntax works for a variable described as you indicated earlier:

stages:
  - stage: FirstStage
    jobs:
      - job: FirstJob
        pool:
          vmImage: 'windows-latest'
        steps:
        - pwsh: Write-Host "deploy custom environment is default"
          displayName: Run if default
          condition: eq(variables['deploy_custom_env'], 'default')
        - pwsh: Write-Host "deploy custom environment is notdefault"
          displayName: Run if not default
          condition: ne(variables['deploy_custom_env'], 'default')

Another way to do it is to not use a variable declared in the UI, but rather a parameter to your build - this will set a default, and it will allow you to change it when queueing a build:

parameters:
- name: deploy_custom_env
  type: string
  default: 'default'

stages:
  - stage: FirstStage
    jobs:
      - job: FirstJob
        pool:
          vmImage: 'windows-latest'
        steps:
        - pwsh: Write-Host "deploy custom environment is default"
          displayName: Run if default
          condition: eq('${{ parameters.deploy_custom_env }}', 'default')
        - pwsh: Write-Host "deploy custom environment is notdefault"
          displayName: Run if not default
          condition: ne('${{ parameters.deploy_custom_env }}', 'default')

This has the advantage of putting the prompt for the value with its default right in front of you when queueing the build - you don't have to drill into the variable.

NOTE: This approach works in a pipeline, it will not work for a condition in a template or nested template, as when a parameter is available can be... tricky.

Thanks for the assistance. It looks like your first suggestion is going to work. I looked back at my git history and your first suggestion is what I tried first, but in that case I was trying to validate against the variable being unset (null? empty string? undefined?). I never went back to that after initializing it to a known string. Thanks again! — erewok, Mar 05 '21 at 21:49
I am now trying the second as well, and I think I prefer it. It'll help the people on my team I'm building this for. Thanks again! — erewok, Mar 05 '21 at 22:07

score 0 · Answer 2 · answered Mar 05 '21 at 18:37

0

If you're doing this in yml file, then $(deploy_custom_env) should work.

answered Mar 05 '21 at 18:37

loganwol

97
1
9

This does not seem to work in a condition because the condition requires an expression (according to the documentation). – erewok Mar 05 '21 at 18:40

Azure Devops Pipeline with Manual Run and User-Set Variables: How to check variables in conditions?

2 Answers2