通过

任务类型和使用情况

  • 项目

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

任务会在流水线中执行一项操作，该操作是已通过一组输入进行提取的打包脚本或过程。 任务是用于在管道中定义自动化的构建基块。

运行作业时，所有任务都按顺序逐一运行。 若要在多个代理上并行运行同一组任务，或者在不使用代理的情况下运行某些任务，请参阅作业。

默认情况下，所有任务都在同一上下文中运行，无论是在主机上，还是在作业容器中。

你可以选择使用步骤目标来控制单个任务的上下文。

详细了解如何使用内置任务为任务指定属性。

运行作业时，所有任务都会在代理商按顺序逐一运行。 若要在多个代理上并行运行同一组任务，或者在不使用代理的情况下运行某些任务，请参阅作业。

要详细了解任务支持的常规属性，请参阅 steps.task 的 YAML 参考。

自定义任务

Azure DevOps 包括内置任务，以实现基本的生成和部署方案。 你也可以创建自己的自定义任务。

此外，Visual Studio Marketplace 提供了许多扩展：每个扩展在安装到订阅或集合时，都会使用一个或多个任务来扩展任务目录。 你还可以编写自己的自定义扩展，以便将任务添加到 Azure Pipelines。

在 YAML 管道中，可以按名称引用任务。 如果一个名称同时符合内置任务和自定义任务，则内置任务优先。 可以对自定义任务使用任务 GUID 或完全限定名称来避免此风险：

steps:
- task: myPublisherId.myExtensionId.myContributionId.myTaskName@1 #format example
- task: qetza.replacetokens.replacetokens-task.replacetokens@3 #working example

若要查找 myPublisherId 和 myExtensionId，请在市场中针对任务选择获取。 URL 字符串中 itemName 后面的值是 myPublisherId 和 myExtensionId。 还可以通过将任务添加到发布管道并在编辑任务时选择查看 YAMLA 来查找完全限定名称。

任务版本

任务将进行版本控制，因此你必须指定管道中使用的任务的主版本。 这有助于防止发布新版本的任务时出现问题。 任务通常向后兼容，但在某些情况下，当任务自动更新时，可能会遇到不可预知的错误。

当新的次版本发布时（例如从 1.2 到 1.3），管道会自动使用新版本。 但如果发布了新的主版本（例如 2.0），则管道将继续使用指定的主版本，直到你编辑管道并手动更改为新的主版本。 日志中将包含有新的主版本可用的提示。

可以通过在 @ 符号后指定任务的完整版本号来设置要使用的次要版本（例如：GoTool@0.3.1）。 只能使用你的组织中存在的任务版本。

在 YAML 中，可在任务名称中使用 @ 指定主版本。 例如，要固定为 PublishTestResults 任务的版本 2：

steps:
- task: PublishTestResults@2

YAML 管道在 TFS 中不可用。

任务控制选项

每个任务都提供一些控制选项。

控件选项可用作 task 部分中的键。

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.

控件选项可用作 task 部分中的键。

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  target: string | target # Environment in which to run this task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.

控件选项可用作 task 部分中的键。

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  target: string | target # Environment in which to run this task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.
  retryCountOnTaskFailure: string # Number of retries if the task fails.

注意

给定的任务或作业无法单方面决定作业/阶段是否继续。 它可以执行的操作是提供成功或失败的状态，每个下游任务/作业都有一个条件计算，条件计算结果决定了是否运行下游任务/作业。 默认条件，即“如果我们处于成功状态，则运行”。

出错时继续会以一种微妙的方式改变这一点。 为了做出这种决策，此条件实际上是“欺骗”了所有下游步骤/作业，将任何结果视为“成功”。 换句话说，此条件的意思是“当你决定有关包含结构的条件时，不要考虑此任务的失败”。

超时期限从任务开始运行时开始。 不包括任务排队或等待代理的时间。

注意

除了任务级别超时之外，管道还可指定任务级别超时。 如果作业级别超时间隔在步骤完成之前已过，则运行作业将终止，即使步骤配置了更长的超时间隔。 有关详细信息，请参阅超时。

在此 YAML 中，即使前一步因 succeededOrFailed() condition 而失败，PublishTestResults@2 也会运行。

steps:
- task: UsePythonVersion@0
  inputs:
    versionSpec: '3.x'
    architecture: 'x64'
- task: PublishTestResults@2
  inputs:
    testResultsFiles: "**/TEST-*.xml"
  condition: succeededOrFailed()

条件

  • 仅当具有相同代理池的所有先前直接和间接依赖项都成功时。 如果有不同的代理池，这些阶段或作业将并发运行。 如果 YAML 中没有设置条件，则此条件是默认条件。

  • 即使以前的依赖项失败，除非运行已取消。 将 YAML 中的 succeededOrFailed() 用于此条件。

  • 即使以前的依赖项失败，即使运行已取消。 将 YAML 中的 always() 用于此条件。

  • 仅当以前的依赖项失败时。 将 YAML 中的 failed() 用于此条件。

步骤目标

任务在执行上下文中运行，所谓的执行上下文是指代理主机或容器。 单个步骤可通过指定 target 来覆盖其上下文。 可用选项是 host，以代理主机以及管道中定义的任何容器为目标。 例如：

resources:
  containers:
  - container: pycontainer
    image: python:3.11

steps:
- task: SampleTask@1
  target: host
- task: AnotherTask@1
  target: pycontainer

在这里，SampleTask 在主机上运行，AnotherTask 在容器中运行。

任务失败后的重试次数

使用 retryCountOnTaskFailure 可指定任务失败时的重试次数。 默认值为零个条目。 有关任务属性的详细信息，请参阅 YAML 架构中的 steps.task。

- task: <name of task>
  retryCountOnTaskFailure: <max number of retries>
   ...

注意

  • 需要代理版本 2.194.0 或更高版本。 在 Azure DevOps Server 2022 上，无代理任务不支持重试。 有关详细信息，请参阅 2021 年 11 月 16 日 Azure DevOps 服务更新 - 自动重试任务，以及 2025 年 6 月 14 日 Azure DevOps 服务更新 - 重试服务器任务。
  • 每次尝试失败后，每次重试之间的等待时间都会增加。 首次重试在数秒后发生。
  • 对于任务的幂等性，不做任何假设。 如果任务具有副作用（例如，如果任务部分创建了外部资源），则可能会在第二次运行时失败。
  • 没有为任务提供关于重试次数的信息。
  • 系统会向任务日志添加一条警告，指示它在重试之前已失败。
  • 所有重试任务尝试都作为同一任务节点的一部分显示在 UI 中。

YAML 管道在 TFS 中不可用。

环境变量

每个任务都有一个 env 属性，该属性是表示映射到任务进程的环境变量的字符串对列表。

- task: AzureCLI@2
  displayName: Azure CLI
  inputs: # Specific to each task
  env:
    ENV_VARIABLE_NAME: value
    ENV_VARIABLE_NAME2: value
  ...

以下示例运行 script 步骤（，此步骤是命令行任务的快捷方式，后跟等效的任务语法。 此示例向 AZURE_DEVOPS_EXT_PAT 环境变量分配一个值，用于通过 Azure DevOps CLI 进行身份验证。

# Using the script shortcut syntax
- script: az pipelines variable-group list --output table
  env:
    AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
  displayName: 'List variable groups using the script step'

# Using the task syntax
- task: CmdLine@2
  inputs:
    script: az pipelines variable-group list --output table
  env:
    AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
  displayName: 'List variable groups using the command line task'


- task: Bash@3
  inputs:
     targetType: # specific to each task
  env:
    ENV_VARIABLE_NAME: value
    ENV_VARIABLE_NAME2: value
  ...

以下示例运行 script 步骤（，此步骤是 Bash@3 的快捷方式，后跟等效的任务语法。 本示例向 ENV_VARIABLE_NAME 环境变量赋值并回显该值。

# Using the script shortcut syntax
- script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: "my value"
  displayName: 'echo environment variable'

# Using the task syntax
- task: Bash@2
  inputs:
    script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: "my value"
  displayName: 'echo environment variable'

生成工具安装程序 (Azure Pipelines)

工具安装程序使生成管道能够安装和控制依赖项。 具体而言，你可以：

  • 针对 CI 生成，即时安装工具或运行时（即使是在 Microsoft 托管的代理上）。

  • 针对依赖项的多个版本（例如 Node.js）验证应用或库。

例如，可以设置生成管道，以便针对多个版本的 Node.js 运行和验证应用。

示例：在多个版本的 Node.js 上测试和验证应用

在项目的基目录中创建包含以下内容的 azure-pipelines.yml 文件。

pool:
  vmImage: ubuntu-latest

steps:
# Node install
- task: UseNode@1
  displayName: Node install
  inputs:
    version: '16.x' # The version we're installing
# Write the installed version to the command line
- script: which node

创建新的生成管道并运行此管道。 观察生成的运行情况。 Node.js 工具安装程序可下载 Node.js 版本（如果尚未安装在代理上）。 命令行脚本可记录 Node.js 版本在磁盘上的位置。

YAML 管道在 TFS 中不可用。

工具安装程序任务

有关工具安装程序任务的列表，请参阅工具安装程序任务。

禁用内置任务和市场任务

在组织设置页上，可以禁用市场任务和/或内置任务。 禁用市场任务有助于提高管道的安全性。 如果同时禁用内置任务和市场任务，则只使用 tfx 有安装的任务可用。

帮助和支持