In this week’s post, we are going to cover some ways to make tasks and jobs run conditionally. This will include options such as Pipeline variables to jobs that are dependent on other jobs. This post will be using a sample Azure DevOps project built over the last few weeks of posts. If you want to see the build-up check out the following posts.
Getting Started with Azure DevOps
Pipeline Creation in Azure DevOps
Azure DevOps Publish Artifacts for ASP.NET Core
Azure DevOps Pipelines: Multiple Jobs in YAML
Azure DevOps Pipelines: Reusable YAML
Azure DevOps Pipelines: Use YAML Across Repos 
Sample YAML
The following YAML is based on the YAML from the previous posts, see links above, expanded with examples of using some ways of conditionally running some task or job. This is the full file for reference and the rest of the post will call out specific parts of the file as needed.
resources:
repositories:
- repository: Shared
name: Playground/Shared
type: git
ref: master #branch name
trigger: none
variables:
buildConfiguration: 'Release'
jobs:
- job: WebApp1
displayName: 'Build WebApp1'
pool:
vmImage: 'ubuntu-latest'
steps:
- template: buildCoreWebProject.yml@Shared
parameters:
buildConFiguration: $(buildConfiguration)
project: WebApp1.csproj
artifactName: WebApp1
- job: WebApp2
displayName: 'Build WebApp2'
condition: and(succeeded(), eq(variables['BuildWebApp2'], 'true'))
pool:
vmImage: 'ubuntu-latest'
steps:
- template: build.yml
parameters:
buildConFiguration: $(buildConfiguration)
project: WebApp2.csproj
artifactName: WebApp2
- job: DependentJob
displayName: 'Build Dependent Job'
pool:
vmImage: 'ubuntu-latest'
dependsOn:
- WebApp1
- WebApp2
steps:
- template: buildCoreWebProject.yml@Shared
parameters:
buildConFiguration: $(buildConfiguration)
project: WebApp1.csproj
artifactName: WebApp1Again
Job Dependencies
The more complex pipelines get the more likely the pipeline will end up with a job that can’t run until other jobs have completed. The YAML above defines three different jobs, WebApp1, WebApp2, and DependentJob. I’m sure you have guessed by now that the third job is the one that has a dependency. To make a job dependent on other jobs we use the dependsOn element and list the jobs that must complete before the job in question can run. The following is the YAML for the sample DependentJob with the dependsOn section highlighted.
- job: DependentJob
displayName: 'Build Dependent Job'
pool:
vmImage: 'ubuntu-latest'
dependsOn:
- WebApp1
- WebApp2
steps:
- template: buildCoreWebProject.yml@Shared
parameters:
buildConFiguration: $(buildConfiguration)
project: WebApp1.csproj
artifactName: WebApp1Again
With the above setup, DependentJob will only run if both the WebApp1 and WebApp2 jobs complete successfully.
Conditions
Conditions are a way to control if a Job or Task is run. The following example is at the job level, but the same concept works at the task level. Notice the highlighted condition.
- job: WebApp2
displayName: 'Build WebApp2'
condition: and(succeeded(), eq(variables['BuildWebApp2'], 'true'))
pool:
vmImage: 'ubuntu-latest'
steps:
- template: build.yml
parameters:
buildConFiguration: $(buildConfiguration)
project: WebApp2.csproj
artifactName: WebApp2
The above condition will cause the WebApp2 job to be skipped if the BuildWebApp2 variable isn’t true. For more details on how to use conditions see the Conditions docs.
Creating a Pipeline Variable
The rest of the post is going to walk through creating a Pipeline variable and then running some sample builds to show how depends on and the conditions defined in the YAML above affect the Pipeline results.
We are starting from an existing pipeline that is already being edited. To add (or edit) variables click the Variables button in the top right of the screen.
The Variables pop out will show. If we had existing variables they show here. Click the New variable button to add a new variable.
We are adding a variable that will control the build of WebApp2 called BuildWebApp2 that defaults to the value of true. Also, make sure and check the Let user override this value when running this pipeline checkbox to allow us to edit this variable when doing a run of the pipeline. Then click the OK button.
Back on the Variables dialog click the Save button.
Edit Variables When Starting a Pipeline
Now that our Pipeline has a variable when running the Pipeline under Advanced options you will see the Variables section showing that our Pipeline has 1 variable defined. Click Variables to view/edit the variables that will be used for this run of the Pipeline.
From the Variables section, you will see a list of the defined variables as well as an option to add new variables that will exist only for this run of the Pipeline. Click on the BuildWebApp2 variable to edit the value that will be used for this run of the Pipeline.
From the Update variable dialog, you can change the value of the variable. When done click the Update button.
Pipeline Results from Sample YAML
The following is what our sample Pipeline looks like when queued with the BuildWebApp2 variable set to false. As you can see the job will be skipped.
Next is the completed results of the Pipeline run. You can see that the Build Dependent Job was skipped as well since both Build WebApp1 and Build WebApp2 must complete successfully before it will run.
Changing the BuildWebApp2 variable back to true and running the Pipeline again results in all the jobs running successfully.
Wrapping Up
Hopefully, this has helped introduce you to some of the ways you can control your Pipelines. As with everything else Azure DevOps related things are changing a lot and new options are popping up all the time. For example, while writing this post the team just announced Runtime Parameters which look like a much better option than variables for values that frequently vary between Pipeline runs.
Also published on Medium.