CODEWITHSUNDEEP
azure-devopsazure-devops-pipelines
erewok
erewok

Reputation: 7835

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

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:

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?

Upvotes: 3

Views: 2100

Answers (2)

WaitingForGuacamole
WaitingForGuacamole

Reputation: 4301

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.

Upvotes: 7

loganwol
loganwol

Reputation: 107

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

Upvotes: 0

Related Questions