In Microsoft Team Foundation Server (TFS) 2018 and previous versions,
build and release pipelines are called definitions,
runs are called builds,
service connections are called service endpoints,
stages are called environments,
and jobs are called phases.
A task is the building block for defining automation in a
pipeline.
A task is simply a packaged script or procedure that has been
abstracted with a set of inputs.
When you add a task to your pipeline, it may also add a set of demands to the pipeline. The demands define the prerequisites that must be installed on the agent for the task to run. When you run the build or deployment, an agent that meets these demands will be chosen.
When you run a job, all the tasks are run in sequence, one after the other, on an agent. To run the same set of tasks in parallel on multiple agents, or to run some tasks without using an agent, see jobs.
In addition, Visual Studio Marketplace
offers a number of extensions; each of which, when installed to your
subscription or collection, extends the task catalog with one or more tasks.
Furthermore, you can write your own custom extensions
to add tasks to Azure Pipelines or TFS.
Task versions
Tasks are versioned, and you must specify the major version of the task used in your
pipeline. This can help to prevent issues when new versions of a task are released.
Tasks are typically backwards compatible, but in some scenarios you may
encounter unpredictable errors when a task is automatically updated.
When a new minor version is released (for example, 1.2 to 1.3), your build or release
will automatically use the new version. However, if a new major version is released
(for example 2.0), your build or release will continue to use the major version you specified
until you edit the pipeline and manually change to the new major version.
The build or release log will include an alert that a new major version is available.
You can set which minor version gets used by specifying the full version number of a task after the @ sign (example: GoTool@0.3.1). You can only use task versions that exist for your organization.
Each task in a pipeline has a Version selector to let you choose the version you want.
If you select a preview version (such as 1.* Preview), be aware that this
version is still under development and might have known issues.
If you change the version and have problems with your builds, you can revert the pipeline change from the History tab.
The ability to restore to an older version of a release pipeline is not currently available. You must manually revert the changes to the release pipeline, then save the pipeline.
Consider cloning the pipeline and testing the cloned pipeline with the new major task version.
Clear this check box to disable a task. This is useful
when you want to temporarily take task out of the process for testing or for specific deployments.
Tip
You can also right-click the task to toggle this setting.
Timeout
The timeout for this task in minutes. The default is zero (infinite timeout).
Setting a value other than zero overrides the setting for the parent task job.
The timeout period begins when the task starts running. It does not include the
time the task is queued or is waiting for an agent.
Azure Pipelines options
Continue on error (partially successful)
Select this option if you want subsequent tasks in the same job to possibly run even if this task fails. The build or deployment will be no better than partially successful. Whether subsequent tasks run depends on the Run this task setting.
Number of retries if task failed
Specify the number of retries if this task fails. The default is zero.
Note
The failing task is retried immediately.
There is no assumption about the idempotency of the task. If the task has side-effects (for instance, if it created an external resource partially), then it may fail the second time it is run.
There is no information about the retry count made available to the task.
A warning is added to the task logs indicating that it has failed before it is retried.
All of the attempts to retry a task are shown in the UI as part of the same task node.
Run this task
Select the condition for running this task:
Only when all previous dependencies with the same agent pool have succeeded. If you have different agent pools, those stages or jobs will run concurrently. This is the default if there is not a condition set in the YAML.
Even if a previous dependency has failed, unless the run was canceled. Use succeededOrFailed() in the YAML for this condition.
Even if a previous dependency has failed, even if the run was canceled. Use always() in the YAML for this condition.
Only when a previous dependency has failed. Use failed() in the YAML for this condition.
If you're running tasks in cases when the build is canceled, then make sure you specify sufficient time for these tasks to run the pipeline options.
TFS 2015 and newer options
Continue on error (partially successful)
Select this option if you want subsequent tasks in the same job to run even if this task fails. The build or deployment will be no better than partially successful.
Always run
Select this check box if you want the task to run even if the build or deployment is failing.
Click Save & queue. Observe how two builds are run. The Node.js Tool Installer downloads each of the Node.js versions if they are not already on the agent. The Command Line task logs the location of the Node.js version on disk.
Tool: Node.js Installer
Utility: Command Line