YAML - Support conditions for templates #1749

CoolDadTx · 2018-08-07T21:51:16Z

Have you tried trouble shooting?

Queuing a build generates an error. Unexpected value 'condition'.

Agent Version and Platform

Version of your agent? 2.102.0/2.100.1/...

OS of the machine running the agent? Windows

VSTS Type and Version

VSTS

If VisualStudio.com, what is your account name? https://fsmb.visualstudio.com

What's not working?

I am trying to set up a YAML build. We have a lot of builds and our existing definitions use task groups. I am moving the task group logic into a template so they can be shared across build definitions. The templates are stored in a separate repository. All this is working correctly.

There is one step that shouldn't execute when it is a PR build so I tried to do this.

- template: sharedstep.yml@templates
  parameters:
     value: true
  condition: and(succeeded(), eq(variables['Build.Reason'], 'PullRequest'))

The build won't queue because of the error - Unexpected value 'condition'.

It would be nice if templates could be conditional like tasks are. Right now the workaround would be to either use a parameter or specify the condition inside the template but the template may not always know the correct condition to use.

Agent and Worker's Diagnostic Logs

It is not queuing so there is no log.

Related Repositories

Please ensure you are logging issues to the correct repository in order to get the best support.

Tasks Repository - contains all of the inbox tasks we ship with VSTS/TFS. If you are having issues with tasks in Build/Release jobs (e.g. unreasonable task failure) please log an issue here.
Hosted Agent Image Repository - contains the VM image used in the VSTS Hosted Agent Pool. If you are having Build/Release failures that seems like they are related to software installed on the Hosted Agent (e.g. the DotnetSDK is missing or the AzureSDK is not on the latest version) please log an issue here.

If you are hitting a generic issue about VSTS/TFS, please report it to the Developer Community

ericsciple · 2018-08-10T18:28:23Z

this is supported:

- ${{ if eq(variables['Build.Reason'], 'PullRequest') }}:
  - template: sharedstep.yml@templates
    parameters:
       value: true

CoolDadTx · 2018-08-10T19:26:07Z

Yes I agree a template would work but the enhancement request is that I be able to use a condition like I can for every other item I can put into a step. Conditions are far easier to write and read then template expressions and the overly complex syntax you have to use to avoid errors.

carct · 2018-09-26T15:26:37Z

i seem to be experiencing some issues with this kind of conditions in yaml`s

child yaml:

${{ if or(eq(variables['Build.SourceBranch'], 'refs/heads/master'), eq(parameters.updateArmTemplate, 'true')) }}:

powershell: |
blabla-my-ps-code

parent yaml:

template: "Pipelines\.vsts-arm-pipeline-template.yml"
parameters:
updateArmTemplate: $(updateArmTemplate)

$(updateArmTemplate) is a variable settable at queue time, with default value 'true' and around the yaml i also have a default value when declaring this parameter in the child yaml

the behavior is that it doesn't get executed although on 'true'
is this a bug or is there something i`m not doing right ?

dhuesmann89 · 2018-09-27T06:44:30Z

I came across this issue yesterday and tried the solution mentioned above and I can confirm that it does not work, the way it is described. Here's part of my yaml:

${{ if eq(variables['ExecuteTests'], '1') }}:

template: ExecuteTests.yml

The same syntax (eq(variables['ExecuteTests'], '1')) works in the condition tag of a single task.

TingluoHuang · 2018-10-05T15:38:45Z

We have created a new repository for all YAML related issues, please move the current issue to there.
https://github.com/Microsoft/azure-pipelines-yaml

TingluoHuang · 2018-10-30T03:23:41Z

move to microsoft/azure-pipelines-yaml#30

MathieuBuisson · 2019-09-13T17:20:23Z

this is supported:

- ${{ if eq(variables['Build.Reason'], 'PullRequest') }}:
  - template: sharedstep.yml@templates
    parameters:
       value: true

@ericsciple
How would this work using an output variable from another task in the same job ?
Thanks.

ericsciple · 2019-09-13T20:57:24Z

@vtbassmatt to redirect

vtbassmatt · 2019-09-16T13:33:08Z

@MathieuBuisson you could do something like this:

# azure-pipelines.yml
steps:
- script: <generate output variable here>
  name: deciderstep
- template: sharedstep.yml@templates
  parameters:
    doTheThing: $[ variables['deciderstep.myVariable'] ]

# sharedstep.yml
steps:
- script: echo Sometimes this happens!
  condition: eq(parameters.doTheThing, 'true')
- script: echo Sometimes this also happens!
  condition: eq(parameters.doTheThing, 'true')

(N.B. I didn't test that, just wrote it from memory, and it may need some tweaking.) It's not as elegant as a conditional inclusion of the template, but does get the scenario working.

afeblot · 2019-12-03T19:12:45Z

I tried that and got an error message stating that "parameters" was unknown here.
Then I tried something like

  condition: eq('${{parameters.doTheThing}}', 'true')

but this did not execute because the parameter was only evaluated as literally $[ variables['deciderstep.myVariable'], which was not true.

Or to be accurate in what I tested, in case it matters, I did not use an output variable but a simple one, and just used this syntax: $(myVariable).

PaulVipond · 2020-02-06T12:56:24Z

I'm using the suggested approach for optional execution of a template:

And get:

/build-templates/steps/node-app-deploy-steps.yml@templates: (Line: 76, Col: 19, Idx: 3882) - (Line: 76, Col: 19, Idx: 3882): Mapping values are not allowed in this context.

If I remove the parameters, then the pipeline compiles, but obviously I need my parameters!

This is a template within a template calling another template - don't know if that's significant.

Update:

It was an indentation issue - 'parameters' should be at the same level as the 'template' keyword. I'll leave it here so that future generations can laugh at my mistake :-)

vtbassmatt · 2020-02-06T13:28:11Z

Nothing to laugh at -- YAML is a confusing beast 😁 Glad you got it solved.

pbalexlear · 2020-04-01T10:13:29Z

Hello @vtbassmat , I am trying to use the example you provided however having some issue such as the one described by @afeblot. When you use the parameter syntax as below
condition: eq(${{parameters.doThething}},true)
this evaluates the parameters at compilation time at which point the variables haven't been set so it evaluates as
condition: eq('variables['deciderstep.myVariable']',true )
which naturally doesn't work, do you have any advice on how to get this working?
also the syntax you described
eq(parameters.doTheThing, 'true')
gives the result:

##[error]Unrecognized value: 'parameters'.

vtbassmatt · 2020-04-01T13:28:20Z

Hi @pbalexlear - we're not doing product support through GitHub issues anymore. Please open a ticket on Developer Community with your scenario.

I'll note a couple of things that may unblock you here:

Your condition section needs to evaluate to something that doesn't wrap the variables['deciderstep'] stuff in single-quotes. My example was correct in this regard.
The parameters suggestion is tricky and may only be applicable to the original person's scenario. The parameter gets consumed statically at compile time and refers to a $[ ] runtime expression. Then the runtime expression has to evaluate correctly at runtime.

pbalexlear · 2020-04-01T13:47:18Z

Thanks for coming back to me @vtbassmatt , I understand what you are saying however, the default action when a parameter is passed into a template seems to be to wrap it as a string or at least this is how it is displayed in the pipeline output as if it is treating it as a string value of the expression.

I understand what you are saying that if the value of a parameter was an expression and wasn't wrapped as a string it would be substituted in and evaluated at runtime, however because the system is wrapping the parameter as a string it doesn't behave this way.

I did manage to find a solution by passing the name of the variable as the value of the parameter, which isn't a solution I like but does work functionally.

If you could advise on how to prevent the system wrapping the expression as a string that would be greatly appreciated.

As I have resolved my issue although through an unideal solution I won't raise a ticket, but would appreciate it if you could advise on the above.

Thanks.

Alex

vtbassmatt · 2020-04-01T15:09:50Z

Your comment made me dig in and try this, and I realized I had a couple of dumb mistakes. The below two files are complete and work the way you'd expect:

# azure-pipelines.yml
pool: { vmImage: ubuntu-latest }
steps:
- checkout: none
- bash: |
    echo Creating output variable...
    echo '##vso[task.setVariable variable=myVariable;isOutput=true]true' # also tested with 'false'
  name: deciderstep
- template: template.yml
  parameters:
    doTheThing: eq(variables['deciderstep.myVariable'], true)

# template.yml
parameters:
  doTheThing: 'false'
steps:
- script: echo This always happens!
  displayName: Always
- script: echo Sometimes this happens!
  condition: ${{ parameters.doTheThing }}
  displayName: Only if true

pbalexlear · 2020-04-01T15:21:32Z

Thanks @vtbassmatt , that's perfect and exactly what I was looking for, thanks very much for taking the time to look into this.

cforce · 2021-02-26T17:47:08Z

Its still not solved how to work in that case with "succeeded()" as this is not supported for templates.

adrian-skybaker · 2021-11-05T03:18:24Z

This would be much simpler and less surprising if the condition element was supported on template.

sebastianrogers · 2022-03-07T13:29:25Z

Useful formulation for suppressing things, for example when you know that part of the environment isn't ready is:

- ${{ if False }}:

JamesDLD · 2022-06-10T07:24:25Z

Thanks! I confirm that the following code is working as expected.

  - ${{ if eq(variables['byPassSlotDeploymentOnDev'], 'true') }}:
    - template: pipeline/web-deploy.yml@Templates
      parameters:
        type: $(type)
        env: dev
        appRoleSuffix: $(appRoleSuffix)
        appRgSuffix: $(appRgSuffix)
        zipDeploymentFilePath: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip

alfredo-milani · 2022-06-10T14:51:00Z

I need to set a variable using the statement:
echo "##vso[task.setvariable variable=environment]${some_value_for_environment}"

And then insert or not a template.
Using the following expression does not works:

- ${{if ne(parameters.some_parameter, variables.environment)}}:
      - script: |
          echo "diff"

- ${{if ne(parameters.some_parameter, variables['environment'])}}:
      - script: |
          echo "diff"

Any suggestions ?

copdips · 2022-06-24T15:46:02Z

Thanks! I confirm that the following code is working as expected.

  - ${{ if eq(variables['byPassSlotDeploymentOnDev'], 'true') }}:
    - template: pipeline/web-deploy.yml@Templates
      parameters:
        type: $(type)
        env: dev
        appRoleSuffix: $(appRoleSuffix)
        appRgSuffix: $(appRgSuffix)
        zipDeploymentFilePath: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip

@JamesDLD
are you sure ? variables in the if clause is not evaluated in run time, in this case it should always be evaluated to null or the default value, but not the case for condition clause where from the need of this issue I think.

copdips · 2022-06-24T15:47:30Z

I need to set a variable using the statement: echo "##vso[task.setvariable variable=environment]${some_value_for_environment}"

And then insert or not a template. Using the following expression does not works:
- ${{if ne(parameters.some_parameter, variables.environment)}}:
      - script: |
          echo "diff"
- ${{if ne(parameters.some_parameter, variables['environment'])}}:
      - script: |
          echo "diff"
Any suggestions ?

this is a pipeline limitation, the variables in the if clause is evaluated from the beginning of the pipeline, not in real time. but as you're using script, not template, so you can use the condition clause, it's real time.

JPardinas · 2022-10-13T14:40:48Z

This is it! I think I got an example of what people is asking for (be creative to implement more custom conditions):

Template condition-example.yml

parameters:
  - name: condition
    displayName: When should send the message
    default: always
    values:
      - always
      - canceled
      - failed
      - succeeded
      - succeededOrFailed

steps:
  - pwsh: |
      $status = "$(Agent.JobStatus)"
      Write-Host "This step was executed because the Pipeline Job Status is $status and the condition is ${{ parameters.condition }}"
    displayName: Echo if condition ${{ parameters.condition }} match
    condition: ${{ parameters.condition }}()

Pipeline call test.yml

stages:
  - stage: TEST

    jobs:
      - job: TEST
        steps:
        - checkout: self
        
        - template: condition-example.yml
          parameters:
            condition: succeeded

        - pwsh: throw "TEST"
          displayName: Throw an error

        - template: condition-example.yml
          parameters:
            condition: succeeded
        
        - template: condition-example.yml
          parameters:
            condition: failed

        - template: condition-example.yml
          parameters:
            condition: succeededOrFailed

        - template: condition-example.yml
          parameters:
            condition: always

        - template: condition-example.yml
          parameters:
            condition: canceled

Result

amanica · 2022-11-01T14:43:52Z

I wanted to do the below, but can't and I don't see an alternative :'(

    - template: my-template.yml
      condition: always()

mikeblakeuk · 2023-03-17T13:28:19Z

/ci/my.yml (Line: x, Col: y): Unrecognized value: 'succeeded'. Located at position 5 within expression: and(succeeded(), eq('${{ parameters.things}}', 'true')). For more help, refer to https://go.microsoft.com/fwlink/?linkid=842996

syedhamjath · 2023-09-21T12:21:04Z

This looks like simple ask. If we dig deeper, I don't how it can be implemented. The template expands during compile time, if we use runtime condition to a template, does that mean we don't want the template to expand during compile time? or we want the condition to applied to the expanded elements?

Not sure, how this can be added to product. Also I really see the benefits of have runtime template selection. This can also cause the pipeline to keep expanding and not know when it will end.

copdips · 2023-09-21T12:34:55Z

@syedhamjath

if we use runtime condition to a template, does that mean we don't want the template to expand during compile time?

yes, it is, just skip the template as unexpanded (implies some azure pipeline GUI change), and mark it in gray,

syedhamjath · 2023-09-22T11:55:00Z

The feedback is given to the community in past and the request was closed due to lack of response from community.
https://developercommunity.visualstudio.com/t/Azure-Pipelines-YAML-Conditional-Run-T/1048083?q=YAML+-+Support+conditions+for+templates

I have recreated the same so please vote to make sure, it gains right attention.
https://developercommunity.visualstudio.com/t/Azure-Pipelines-YAML-Conditional-Run-T/10473620

bakersagar · 2023-09-29T11:04:30Z

${{ if succeeded() }}:
- template: mytemplate

What's the solution for checking if the previous task succeeded?

JPardinas · 2023-09-29T11:18:14Z

${{ if succeeded() }}:

template: mytemplate

What's the solution for checking if the previous task succeeded?

You can implement something like the following:

mytemplate.yml

parameters:
  - name: condition
    displayName: When to create the tag and push it
    type: string
    default: succeeded()

steps:
    - bash: echo "${{ parameters.condition }}"
      displayName: Step with inherited condition from template parameter ${{ parameters.condition }}
      condition: ${{ parameters.condition }}

    - bash: |
           echo "${{ parameters.condition }}"
           echo "Executed because parameter condition is true or branch is main"
      displayName: Another step with inherited condition from template parameter ${{ parameters.condition }}
      condition: or(${{ parameters.condition }}, eq(variables['Build.SourceBranch'], 'refs/heads/main'))

pipeline.yml

...
    - template: mytemplate.yml
      parameters:
        condition: always()

A-Rai-col · 2024-02-29T16:07:22Z

What if I want to run different templates based on conditions within the same job?

For example.

- template: build-template.yml
  condition: and(succeeded(), eq(variables.IsReleaseBranch, false))

- template: release-template.yml
  condition: and(succeeded(), eq(variables.IsReleaseBranch, true))

copdips · 2024-02-29T19:51:19Z

What if I want to run different templates based on conditions within the same job?

For example.
- template: build-template.yml
  condition: and(succeeded(), eq(variables.IsReleaseBranch, false))

- template: release-template.yml
  condition: and(succeeded(), eq(variables.IsReleaseBranch, true))

is this working for you?

A-Rai-col · 2024-03-04T11:12:18Z

Hi @copdips thanks for the reply!

is this working for you?

No it doesn't, with the following error message Unexpected value 'condition'.

Here's more code context:

variables:
  IsReleaseBranch: $[startsWith(variables['Build.SourceBranch'], 'refs/heads/release/')]
stages:
  - stage: Build
    jobs: 
      - job: Deploy
        pool:
          vmImage: 'windows-latest'
        steps:
          - script: echo `build`

          - template: build-template.yml 
            condition: and(succeeded(), eq(variables.IsReleaseBranch, false))

          - template: release-template.yml
            condition: and(succeeded(), eq(variables.IsReleaseBranch, true))

The variable IsReleaseBranch can either be true or false on each stage:job run, therefore only one of the step templates should be used.

Want I want to do is to use different step/task level templates based on a variable ^(preferable) or parameter.
Is there a way this can be done?

copdips · 2024-03-04T17:06:40Z

AFIK, and based on the other comments in this issue, no ...
This is a vendor design.

TingluoHuang added the Area: YAML label Aug 10, 2018

ericsciple added the enhancement label Aug 10, 2018

ericsciple assigned chrispat and bryanmacfarlane Aug 20, 2018

TingluoHuang mentioned this issue Oct 30, 2018

Support conditions for templates microsoft/azure-pipelines-yaml#30

Closed

TingluoHuang closed this as completed Oct 30, 2018

ericsciple unassigned chrispat and bryanmacfarlane Sep 13, 2019

YAML - Support conditions for templates #1749

YAML - Support conditions for templates #1749

Comments

CoolDadTx commented Aug 7, 2018

Have you tried trouble shooting?

Agent Version and Platform

VSTS Type and Version

What's not working?

Agent and Worker's Diagnostic Logs

Related Repositories

ericsciple commented Aug 10, 2018 • edited

CoolDadTx commented Aug 10, 2018

carct commented Sep 26, 2018 • edited

dhuesmann89 commented Sep 27, 2018

TingluoHuang commented Oct 5, 2018

TingluoHuang commented Oct 30, 2018

MathieuBuisson commented Sep 13, 2019

ericsciple commented Sep 13, 2019

vtbassmatt commented Sep 16, 2019

afeblot commented Dec 3, 2019

PaulVipond commented Feb 6, 2020 • edited

vtbassmatt commented Feb 6, 2020

pbalexlear commented Apr 1, 2020 • edited

vtbassmatt commented Apr 1, 2020

pbalexlear commented Apr 1, 2020

vtbassmatt commented Apr 1, 2020

pbalexlear commented Apr 1, 2020

cforce commented Feb 26, 2021

adrian-skybaker commented Nov 5, 2021

sebastianrogers commented Mar 7, 2022

JamesDLD commented Jun 10, 2022

alfredo-milani commented Jun 10, 2022 • edited

copdips commented Jun 24, 2022

copdips commented Jun 24, 2022 • edited

JPardinas commented Oct 13, 2022 • edited

amanica commented Nov 1, 2022

mikeblakeuk commented Mar 17, 2023

syedhamjath commented Sep 21, 2023

copdips commented Sep 21, 2023 • edited

syedhamjath commented Sep 22, 2023 • edited

bakersagar commented Sep 29, 2023

JPardinas commented Sep 29, 2023

A-Rai-col commented Feb 29, 2024 • edited

copdips commented Feb 29, 2024

A-Rai-col commented Mar 4, 2024 • edited

copdips commented Mar 4, 2024

ericsciple commented Aug 10, 2018 •

edited

carct commented Sep 26, 2018 •

edited

PaulVipond commented Feb 6, 2020 •

edited

pbalexlear commented Apr 1, 2020 •

edited

alfredo-milani commented Jun 10, 2022 •

edited

copdips commented Jun 24, 2022 •

edited

JPardinas commented Oct 13, 2022 •

edited

copdips commented Sep 21, 2023 •

edited

syedhamjath commented Sep 22, 2023 •

edited

A-Rai-col commented Feb 29, 2024 •

edited

A-Rai-col commented Mar 4, 2024 •

edited