In this article, we are going to learn about executing a particular Pipeline Task based on conditions.
![Pipeline Task]()
Introduction
Azure DevOps – Pipelines support conditional execution of a Task. It means we can control the execution of the task based on a condition and decide if we want to execute it. Azure DevOps supports the below types of conditions
- Built-In Condition
- Custom Condition
Scenario
An Azure DevOps Pipeline is a set of Tasks which are executed in a sequence by the Agent. Sometimes, it may be required to execute a particular task based on some logical condition. Below are some scenarios.
Built-In Conditions
- Execute one of the Pipeline tasks (say AuditLog) only when the rest of ALL pipeline Tasks fail. The AuditLog task could log some details about the failure of all tasks.
- Execute one of the Pipeline Tasks only when its dependent task(s) fails.
You can also have your own custom conditions to control the execution of the Tasks. Below are a few examples.
Custom Conditions
- Execute one of the Pipeline Tasks ONLY if the value of a variable is true.
- Execute one of the Pipeline Task ONLY if the current branch is develop.
- Execute the Pipeline ONLY if the pipeline is executed automatically (Continuous Integration).
Solution
Let’s first see how to leverage the built-in conditions and learn how to control them based on the built-in conditions. Below are the built-in conditions and their usage.
Note. By default, each Task (Jobs and Stages) has a built-in dependency on the previous Task, which means, that if the previous task fails, then the current task will not be executed.
Built-In Conditions
Below are the built-in conditions that can be used to control the execution of tasks.
| Condition Criteria |
Description |
| succeeded() |
Runs ONLY when its dependent task is Succeeded. It’s the default behavior. |
| failed() |
Runs ONLY when its dependency has failed. |
| succeeded or failed() |
Runs when its previous depended task is succeeded of failed. It won’t run when pipeline execution is cancelled. |
| always() |
Runs ALL the time irrespective of the status of the previous dependent tasks or even if the pipeline execution is cancelled forcefully. |
Below is an example of the usage of the failed() condition at a Job level. Similarly, it could be used at individual Tasks or even Stage levels.
![Individual Task]()
The above screenshot is a pipeline with two jobs where the 1st job has an error which is created intentionally. Below are the points to note from the above pipeline.
- Job1 fails as there is a typo in Line: 17. It should be Write-Host instead of Write-Hosts
- Job2 gets executed even though Job1 fails because it is dependent on Job1 and a condition failed() is specified.
Let’s now learn how to use custom conditions to control the execution of Tasks. In this scenario, you may want to execute a Task / Job / Stage when the value of a variable is set to true. Let's see how to configure it.
Create a variable as shown below and set it to true.
![Variables]()
In the pipeline, add the condition as shown below to control the execution only when the variable ExecuteTaskBasedonCondtion is set to true.
![ExecuteTask]()
In the above screenshot, a condition is used to control the execution of the Task based on the value of a variable.
If the value of the variable ExecuteTaskBasedonCondition is set to true then the Task will execute otherwise it will be skipped. Below is a screenshot which shows that the task is skipped when the value of the variable is set to false.
More above the Condition Expression
- Here the variable is referred to using the Variables construct instead of regular $(variable name) syntax.
- eq is a function that takes two parameters and returns true if both of the inputs are the same. Otherwise, returns false.
In this Tip, we have learnt how to add a very simple condition. For various scenarios, refer to the official documentation here.
Summary
In this Tip, we have learnt how to control the execution of a Task / Job / Stage based on the conditions.
Feel free to share your feedback in the comments section. Thanks for reading.