YAML 管道中的资源

项目
08/28/2024

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

本文讨论 YAML 管道的资源。资源是指存在于管道外部的管道所使用的任何东西。定义资源时，可以在管道中的任意位置使用资源。

资源提供管道中使用的服务（包括版本、生成工件、关联的提交和工作项）的完全可跟踪性。还可以通过订阅资源上的触发事件来完全自动化 DevOps 工作流。

资源架构

YAML 中的资源表示管道、生成、存储库、容器、包和 Webhook 的源。有关完整的架构信息，请参阅 Azure Pipelines 的 YAML 架构参考中的资源定义。

当资源触发管道时，将设置以下变量：

resources.triggeringAlias
resources.triggeringCategory

变量 Build.Reason 必须为 ResourceTrigger 才能设置这些值。如果资源未触发管道运行，则这些值为空。

管道资源定义

如果有生成生成工件的管道，可以通过定义 pipelines 资源来使用生成工件。只有 Azure Pipelines 可以使用 pipelines 资源。可以在管道资源上为持续部署 (CD) 工作流设置触发器。

在资源定义中，pipeline 是一个唯一值，稍后可以使用该值来引用管道中的管道资源。 source 是生成管道项目的管道的名称。有关完整的架构信息，请参阅 resources.pipelines.pipeline 定义。

可以使用 pipeline 定义的标签引用其他管道部分的管道资源，例如使用管道资源变量或下载生成工件时。有关下载管道项目的替代方法，请参阅下载项目。

重要

定义管道资源触发器时：

如果 pipeline 资源与当前管道来自同一存储库，或者 self，则触发将遵循引发事件的同一分支和提交。
如果管道资源来自不同的存储库，则当前管道将在 pipeline 资源存储库的默认分支上触发。

管道资源定义示例

以下示例使用同一项目中管道中的项目。

resources:
  pipelines:
  - pipeline: SmartHotel-resource # identifier to use in pipeline resource variables
    source: SmartHotel-CI # name of the pipeline that produces the artifacts

要使用另一个项目的管道，请包括项目名称和源名称。以下示例使用 branch 来解析手动或计划触发管道时的默认版本。分支输入不能有通配符。

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    branch: releases/M142

以下示例显示了一个包含简单触发器的管道资源。

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger: true

以下示例显示了具有分支条件的管道资源 trigger。

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
      - releases/*
      - resources.triggeringAlias

以下示例使用 stages 筛选器来评估 CD 管道的触发器条件。阶段使用 AND 运算符。成功完成所有提供阶段后，CD 管道将触发。

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:
      - PreProduction
      - Production

以下示例使用 tags 筛选器进行默认版本评估和触发器。标记使用 AND 运算符。

tags 设置在持续集成 (CI) 或 CD 管道上。这些标记不同于 Git 存储库中的分支上设置的标记。

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    tags: 
    - Production 
    trigger:
      tags:
      - Production
      - Signed

管道项目版本评估

资源管道项目的版本取决于管道的触发方式。

手动或计划触发器

如果管道运行是手动触发或计划的，则 version、branch 和 tags 属性的值定义了项目版本。 branch 输入不能有通配符。 tags 属性使用 AND 运算符。

指定的属性	生成工件版本
`version`	来自具有指定运行编号的生成的生成工件
`branch`	来自在指定分支上完成的最新生成的生成工件
`tags` 列表	来自具有所有指定标记的最新生成的生成工件
`branch` 和 `tags` 列表	来自在指定分支上完成且具有所有指定标记的最新生成的项目
无	来自所有分支中的最新生成的生成工件

以下 pipeline 资源定义使用 branch 和 tags 属性在手动或计划管道时评估默认版本。手动触发管道运行时，MyCIAlias 管道工件版本是 main 分支上完成且具有 Production 和 PrepProduction 标记的最新生成。

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main
    tags:
    - Production
    - PreProduction

资源管道完成触发器

当管道因其中一个资源管道完成而触发时，工件版本是触发管道的版本。忽略 version、branch 和 tags 属性的值。

指定的触发器	业务成效
`branches`	每当资源管道在 `include` 分支之一上成功完成运行时，就会触发新的管道运行。
`tags`	每当资源管道成功完成标记有所有指定标记的运行时，就会触发新的管道运行。
`stages`	每当资源管道成功执行指定的 `stages` 时，就会触发新的管道运行。
`branches`、`tags` 和 `stages`	每当资源管道运行满足所有分支、标记和阶段条件时，就会触发新的管道运行。
`trigger: true`	每当资源管道成功完成运行时，就会触发新的管道运行。
无	当资源管道成功完成运行时，不会触发新的管道运行。

每当 SmartHotel-CI 资源管道运行时，以下管道都会运行：

在 releases 分支之一或 main 分支上运行
标记有 Verified 和 Signed
完成 Production 和 PreProduction 两个阶段

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
        include:
        - releases/*
        - main
        exclude:
        - topic/*
      tags: 
      - Verified
      - Signed
      stages:
      - Production
      - PreProduction

管道工件下载

download 步骤下载与当前运行或其他管道资源相关的工件。

将自动下载当前管道和所有 pipeline 资源中的所有生成工件，并在每个部署作业开始时提供。可以通过将 download 设置为 none 或指定另一个管道资源标识符来替代此行为。

不会自动下载常规作业工件。在需要时显式使用 download。

来自 pipeline 资源的工件被下载到 $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier> 文件夹。有关详细信息，请参阅发布和下载管道工件。

可选 artifact 属性指定工件名称。如果未指定，则下载所有可用工件。可选 patterns 属性定义表示要包含的文件的模式。有关完整架构信息，请参阅 steps.download 定义。

- job: deploy_windows_x86_agent
  steps:
  - download: SmartHotel
    artifact: WebTier1
    patterns: '**/*.zip'

管道资源变量

在每个运行中，管道资源的元数据作为预定义变量可供所有作业使用。这些变量仅在运行时对管道可用，因此不能在模板表达式中使用，模板表达式在管道编译时求值。

有关详细信息，请参阅作为预定义变量的管道资源元数据。要了解有关变量语法的详细信息，请参阅定义变量。

以下示例返回 myresourcevars 管道资源的预定义变量值。

resources:
  pipelines:
  - pipeline: myresourcevars
    source: mypipeline
    trigger: true 

steps:
- script: |
    echo $(resources.pipeline.myresourcevars.pipelineID)
    echo $(resources.pipeline.myresourcevars.runName)
    echo $(resources.pipeline.myresourcevars.runID)
    echo $(resources.pipeline.myresourcevars.runURI)
    echo $(resources.pipeline.myresourcevars.sourceBranch)
    echo $(resources.pipeline.myresourcevars.sourceCommit)
    echo $(resources.pipeline.myresourcevars.sourceProvider)
    echo $(resources.pipeline.myresourcevars.requestedFor)
    echo $(resources.pipeline.myresourcevars.requestedForID)

生成资源定义

如果有生成了工件的外部 CI 生成系统，则可以将工件与 builds 资源一起使用。 build 资源可以来自任何外部 CI 系统，例如 Jenkins、TeamCity 或 CircleCI。

builds 类别是一个可扩展类别。可以编写扩展以使用生成服务中的工件，并引入一种新型服务作为 builds 的一部分。

在 build 定义中，version 默认为最新的成功生成。默认情况下，trigger 未启用，必须显式设置。有关完整的架构信息，请参阅 resources.builds.build 定义。

在以下示例中，Jenkins 是资源 type。

resources:
  builds:
  - build: Spaceworkz
    type: Jenkins
    connection: MyJenkinsServer 
    source: SpaceworkzProj   # name of the Jenkins source project
    trigger: true

重要

仅托管的 Jenkins 支持触发器，其中 Azure DevOps 与 Jenkins 服务器有联系。

downloadBuild 任务

build 资源工件不会自动下载到 jobs/deploy-jobs 中。要将 build 资源中的工件作为作业的一部分使用，需要显式添加 downloadBuild 任务。可以为每个部署或作业自定义下载行为。

此任务会自动解析为运行时定义的 build 资源类型的相应下载任务。来自 build 资源的工件被下载到 $(PIPELINE.WORKSPACE)/<build-identifier>/ 文件夹中。

在 downloadBuild 定义中，可以指定从中下载工件的资源。可选 artifact 属性指定要下载的工件。如果未指定，则下载与资源关联的所有工件。

可选 patterns 属性定义要下载的最小匹配路径或最小匹配路径列表。如果为空，则下载整个工件。例如，以下代码片段仅下载 *.zip 文件。

- job: deploy_windows_x86_agent
  steps:
  - downloadBuild: Spaceworkz
    patterns: '**/*.zip'

有关完整架构信息，请参阅 steps.downloadBuild 定义。

存储库资源定义

使用 repository 关键字可以指定外部存储库。如果管道在另一个存储库中具有模板，或者你想要对需要服务连接的存储库使用多存储库签，则可以使用此资源。必须让系统知道这些存储库。

例如：

resources:
  repositories:
  - repository: common
    type: github
    name: Contoso/CommonTools
    endpoint: MyContosoServiceConnection

有关完整架构信息，请参阅 resources.repositories.repository 定义。

存储库资源类型

Azure Pipelines 支持存储库类型的以下值：git、github、githubenterprise 和 bitbucket。

git 类型引用 Azure Repos Git 存储库。
GitHub Enterprise 存储库需要 GitHub Enterprise 服务连接进行授权。
Bitbucket 云存储库需要 Bitbucket 云服务连接进行授权。

类型	名称值	示例
`type: git`	同一项目或同一组织中的另一个存储库。	同一个项目：`name: otherRepo` 同一组织中的另一个项目：`name: otherProject/otherRepo`。
`type: github`	GitHub 存储库的全名，包括用户或组织。	`name: Microsoft/vscode`
`type: githubenterprise`	GitHub Enterprise 存储库的全名，包括用户或组织。	`name: Microsoft/vscode`
`type: bitbucket`	Bitbucket 云存储库的全名，包括用户或组织。	`name: MyBitbucket/vscode`

存储库资源变量

在每个运行中，存储库资源的以下元数据可供采用运行变量形式的所有作业使用。 <Alias> 是你为存储库资源指定的标识符。

resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.url

以下示例具有一个别名为 common 的存储库资源，因此存储库资源变量可以使用 resources.repositories.common.* 访问。

resources:
  repositories:
    - repository: common
      type: git
      ref: main
      name: Repo

variables:
  ref: $[ resources.repositories.common.ref ]
  name: $[ resources.repositories.common.name ]
  id: $[ resources.repositories.common.id ]
  type: $[ resources.repositories.common.type ]
  url: $[ resources.repositories.common.url ]

steps:
- bash: |
    echo "name = $(name)"
    echo "ref = $(ref)"
    echo "id = $(id)"
    echo "type = $(type)"
    echo "url = $(url)"

在每个运行中，存储库资源的以下元数据可供采用运行变量形式的所有作业使用。 <Alias> 是你为存储库资源指定的标识符。

resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.url
resources.repositories.<Alias>.version

以下示例具有一个别名为 common 的存储库资源，因此存储库资源变量可以使用 resources.repositories.common.* 访问。

resources:
  repositories:
    - repository: common
      type: git
      ref: main
      name: Repo

variables:
  ref: $[ resources.repositories.common.ref ]
  name: $[ resources.repositories.common.name ]
  id: $[ resources.repositories.common.id ]
  type: $[ resources.repositories.common.type ]
  url: $[ resources.repositories.common.url ]
  version: $[ resources.repositories.common.version ]

steps:
- bash: |
    echo "name = $(name)"
    echo "ref = $(ref)"
    echo "id = $(id)"
    echo "type = $(type)"
    echo "url = $(url)"
    echo "version = $(version)"

签出存储库的关键字

repository 资源中的存储库不会在作业中自动同步。使用 checkout 关键字提取定义为 repository 资源的一部分的存储库。有关完整架构信息，请参阅 steps.checkout 定义。

有关详细信息，请参阅在管道中签出多个存储库。

容器资源定义

如果需要将容器映像作为 CI/CD 管道的一部分使用，可以使用 containers 资源。 container 资源可以是公共或专用 Docker 注册表，也可以是 Azure 容器注册表实例。

可以将通用容器资源映像作为作业的一部分使用，也可以将该资源用于容器作业。如果管道需要一个或多个服务的支持，则需要创建并连接到服务容器。可以使用卷分享服务之间的数据。

如果需要使用 Docker 注册表中的映像作为管道的一部分，可以定义通用容器资源。不需要任何 type 关键字。例如：

resources:         
  containers:
  - container: smartHotel 
    endpoint: myDockerRegistry
    image: smartHotelApp

有关完整架构信息，请参阅 resources.containers.container 定义。

注意

用于为所有映像标记启用容器触发器的 enabled: 'true' 语法不同于用于其他资源触发器的语法。请务必对特定资源使用正确的语法。

Azure 容器注册表资源类型

若要使用 Azure 容器注册表映像，可以使用一级容器资源类型 acr。可以将此资源类型用作作业的一部分，并启用自动管道触发器。

需要具有对 Azure 容器注册表的参与者或所有者权限，才能使用自动管道触发器。有关详细信息，请参阅 Azure 容器注册表角色和权限。

若要使用 acr 资源类型，必须为 Azure 容器注册表指定 azureSubscription、resourceGroup 和 repository 值。例如：

resources:         
  containers:
  - container: petStore      
    type: acr  
    azureSubscription: ContosoConnection
    resourceGroup: ContosoGroup
    registry: petStoreRegistry
    repository: myPets
    trigger: 
      tags:
        include: 
        - production*

注意

触发器评估仅在默认分支发生。请确保设置了正确的默认分支，或将 YAML 文件合并到当前的默认分支中。有关如何更改管道默认分支的详细信息，请访问管道默认分支。

容器资源变量

将容器定义为资源后，容器映像元数据作为变量传递到管道。可以在容器部署任务中使用的所有作业中访问映像、注册表和连接详细信息等信息。

容器资源变量适用于 Docker 和 Azure 容器注册表。不能将容器资源变量用于本地映像容器。 location 变量仅适用于 acr 类型的容器资源。

以下示例有一个名为 arm-connection 的Azure 资源管理器服务连接。有关详细信息，请参阅 Azure 容器注册表、存储库和映像。

resources:
  containers:
  - container: mycontainer
    type: ACR
    azureSubscription: arm-connection
    resourceGroup: rg-storage-eastus
    registry: mycontainerregistry
    repository: hello-world
    trigger:
      tags:
      - latest

steps:
- script: echo |
    echo $(resources.container.mycontainer.type)
    echo $(resources.container.mycontainer.registry)
    echo $(resources.container.mycontainer.repository)
    echo $(resources.container.mycontainer.tag)
    echo $(resources.container.mycontainer.digest)
    echo $(resources.container.mycontainer.URI)
    echo $(resources.container.mycontainer.location)

包资源定义

可以使用 NuGet 和 npm GitHub 包作为 YAML 管道中的资源。若要在新包版本发布时启用自动管道触发器，请将 trigger 属性设置为 true。

定义 package 资源时，请在 name 属性中指定包 <Repository>/<Name>，并将包 type 设置为 NuGet 或 npm。要使用 GitHub 包，请使用基于个人访问令牌 (PAT) 的身份验证，并创建使用 PAT 的 GitHub 服务连接。

有关完整架构信息，请参阅 resources.packages.package 定义。

默认情况下，包不会自动下载到作业中。若要下载，请使用 getPackage。

以下示例有一个名为 contoso 的 GitHub npm 包的 GitHub 服务连接（名为 pat-contoso）。有关详细信息，请参阅 GitHub 包。

resources:
  packages:
    - package: contoso
      type: npm
      connection: pat-contoso
      name: myname/contoso 
      version: 7.130.88 
      trigger: true

pool:
  vmImage: 'ubuntu-latest'

steps:
- getPackage: contoso

Webhook 资源定义

注意

Webhook 已于 2020 年 1 月在 Azure DevOps Server 中发布。

可以使用工件，并使用管道、容器、生成和包资源启用自动触发器。但是，不能使用这些资源来基于外部事件或服务自动执行部署过程。

YAML 管道中的 webhooks 资源允许将管道与 GitHub、GitHub Enterprise、Nexus 和 Artifactory 等外部服务集成，以自动执行工作流。可以通过 Webhook 订阅任何外部事件，并使用这些事件触发管道。

Webhook 基于第一类资源（例如管道、生成、容器或包）不支持的任何外部 Webhook 事件自动执行工作流。此外，对于 Azure DevOps 无法了解过程的本地服务，可以在服务上配置 Webhook 并自动触发管道。

要订阅 Webhook 事件，请在管道中定义 Webhook 资源，并将其指向传入 Webhook 服务连接。还可以基于 JSON 有效负载数据在 Webhook 资源上定义更多筛选器，以自定义每个管道的触发器。

每当传入 Webhook 服务连接收到 Webhook 事件时，都会为订阅 Webhook 事件的所有管道触发新的运行。可以使用格式 ${{ parameters.<WebhookAlias>.<JSONPath>}} 将作业中的 JSON 有效负载数据作为变量使用。

有关完整架构信息，请参阅 resources.webhooks.webhook 定义。

以下示例定义 Webhook 资源：

resources:
  webhooks:
    - webhook: WebHook
      connection: IncomingWH

steps:  
- script: echo ${{ parameters.WebHook.resource.message.title }}

Webhook 触发器

若要配置 Webhook 触发器，首先需要在外部服务上设置 Webhook，并提供以下信息：

请求 URL：https://dev.azure.com/<Azure DevOps organization>/_apis/public/distributedtask/webhooks/<webhook name>?api-version=6.0-preview
密钥（可选）：如果需要保护 JSON 有效负载，请提供密钥值。

接下来，创建一个新的传入 Webhook 服务连接。对于此服务连接类型，可以定义以下信息：

WebHook 名称：与在外部服务中创建的 Webhook 相同。
密钥（可选）：用于验证有效负载的 HMAC-SHA1 哈希，该哈希用于验证传入请求。如果在创建 Webhook 时使用了机密，则必须提供相同的机密。
HTTP 标头：请求中的 HTTP 标头，其中包含有效负载的 HMAC-SHA1 哈希值，用于请求验证。例如，GitHub 请求标头为 X-Hub-Signature。

显示传入 Webhook 服务连接的屏幕截图。

要使用 Webhook 触发管道，需要向 https://dev.azure.com/<org_name>/_apis/public/distributedtask/webhooks/<webhook_connection_name>?api-version=6.0-preview 发出 POST 请求。此终结点公开可用，无需授权。请求的正文应如下例所示：

{
    "resource": {
        "message": {
            "title": "Hello, world!",
            "subtitle": "I'm using WebHooks!"
        }
    }
}

注意

从 Webhook 的请求正文访问数据可能会导致错误的 YAML。例如，管道步骤 - script: echo ${{ parameters.WebHook.resource.message }} 会提取整个 JSON 消息，这会生成无效的 YAML。通过此 Webhook 触发的任何管道都不会运行，因为生成的 YAML 变得无效。

以下代码片段演示了使用 Webhook 筛选器的另一个示例。

resources:
  webhooks:
    - webhook: MyWebhookTrigger          
      connection: MyWebhookConnection    
      filters:
        - path: repositoryName      
          value: maven-releases     
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

资源的手动版本选取器

手动触发 CD YAML 管道时，Azure Pipelines 会根据提供的输入自动评估管道中定义的资源的默认版本。但是，Azure Pipelines 在评估计划触发器的默认版本时，或者如果你没有手动选择版本，则只考虑成功完成的 CI 运行。

创建运行时，可以使用资源版本选取器手动选择其他版本。管道、生成、存储库、容器和包资源支持资源版本选取器。

对于管道资源，可以查看所有分支中的所有可用运行，根据管道编号或分支进行搜索，并选择成功、失败或正在进行的运行。这种灵活性可确保你能够运行 CD 管道（如果你确定运行所需的所有工件）。无需等待 CI 运行完成或重新运行，因为出现不相关的阶段故障。

若要使用资源版本选取器，请在运行管道窗格中选择资源，然后从可用版本列表中选择特定版本。

显示存储库资源版本选取器的屏幕截图。

对于无法获取可用版本的资源（如 GitHub 包），版本选择器提供了一个文本字段，以便你可以输入要选择的运行版本。

YAML 管道中的资源授权

必须先对资源进行授权，然后才能在管道中使用资源。资源所有者控制可以访问其资源的用户和管道。有几种方法可以授权 YAML 管道使用资源。

使用资源管理体验授权所有管道访问资源。例如，变量组和安全文件在管道下的库页面中管理，代理池和服务连接在项目设置中管理。如果不需要限制对资源的访问（例如，测试资源），则此授权很方便。
创建管道时，如果你对这些资源具有用户角色，则 YAML 文件中引用的所有资源都会自动获得授权供管道使用。
如果你在 YAML 文件中添加了一个资源，但生成失败并出现类似 Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use. 的错误，你会看到一个选项，用于授权失败生成上的资源。

如果你是资源的用户角色的成员，则可以选择此选项，并在失败的生成上授权资源。资源获得授权后，可以启动新的生成。
验证项目的代理池安全角色是否正确。

资源的审批检查

可以使用审批检查和模板手动控制资源何时运行。使用所需的模板审批检查，可以要求使用资源或环境的任何管道从特定的 YAML 模板扩展。

设置所需的模板审批可确保仅在特定条件下使用资源，并增强安全性。要了解有关如何使用模板增强管道安全性的详细信息，请参阅使用模板实现安全性。

可跟踪性

Azure Pipelines 为在管道或部署作业级别使用的任何资源提供完全可跟踪性。

管道可跟踪性

Azure Pipelines 为每个管道运行显示以下信息：

如果资源触发了管道，则触发管道的资源。
资源版本和所用的工件。
与每个资源关联的提交。
与每个资源关联的工作项。

环境可跟踪性

每当管道部署到环境时，你都可以看到已使用的资源列表。视图包括作为部署作业的一部分使用的资源及其关联的提交和工作项。

显示环境中提交的屏幕截图。

CI 管道中关联的 CD 管道信息

为了提供端到端的可跟踪性，可以通过 pipelines 资源跟踪哪些 CD 管道使用特定的 CI 管道。如果其他管道使用 CI 管道，运行视图中会显示关联的管道选项卡。该视图显示了使用 CI 管道的所有 CD YAML 管道运行以及其中的工件。

显示 CI 管道中的 CD 管道信息的屏幕截图。

资源触发器问题

资源触发器可能执行失败，因为：

提供的服务连接的源无效，触发器中存在语法错误，或者触发器未配置。
触发器条件不匹配。

要查看管道触发器执行失败的原因，请在管道定义页面上选择触发器问题菜单项。 触发器问题仅适用于非存储库资源。

在触发器问题页上，错误和警告消息描述触发器失败的原因。

显示触发器问题可支持性的屏幕截图。

常见问题解答

我应该在什么时候使用管道资源、下载快捷方式或下载管道工件任务？

使用 pipelines 资源是使用 CI 管道中的生成工件并配置自动触发器的一种方法。资源通过显示所使用的版本、生成工件、提交和工作项，使你能够完全了解过程。定义管道资源时，关联的生成工件会自动下载到部署作业中。

可以使用 download 快捷方式下载生成作业中的工件，或替代部署作业中的下载行为。有关详细信息，请参阅 steps.download 定义。

下载管道工件任务不提供可跟踪性或触发器，但有时直接使用此任务是有意义的。例如，你可能有一个脚本任务存储在不同的模板中，该脚本任务需要从生成中下载工件。或者，你可能不想将管道资源添加到模板中。为了避免依赖关系，可以使用“下载管道工件”任务将所有生成信息传递给任务。

更新 Docker Hub 映像时，如何触发管道运行？

因为容器资源触发器不适用于 YAML 管道的 Docker Hub，因此需要设置经典发布管道

创建新的 Docker Hub 服务连接。
创建经典发布管道并添加 Docker Hub 生成工件。设置服务连接，并选择命名空间、存储库、版本和源别名。
选择触发器并将持续部署触发器切换为“启用”。每次对所选存储库执行 Docker 推送时，都会创建一个发布。
创建新阶段和作业。添加两个任务：Docker 登录和 Bash。
- Docker 任务具有 login 操作并登录到 Docker Hub。
- Bash 任务运行 docker pull <hub-user>/<repo-name>[:<tag>]。

如何验证 Webhook 并排查其中的问题？

创建服务连接。

在 webhooks 部分中引用服务连接并命名 Webhook。

resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias
      connection: MyServiceConnection

运行管道。 Webhook 是在 Azure 中为组织创建的分布式任务。
使用正文中的有效 JSON 对 https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion> 执行 POST API 调用。如果收到 200 状态代码响应，则表示 Webhook 已就绪，可供管道使用。

如果收到 500 状态代码响应以及错误 Cannot find webhook for the given webHookId ...，则代码可能位于默认分支以外的分支中。若要解决此问题：

在管道页上选择编辑。
从更多操作菜单中，选择触发器。
选择 YAML 选项卡，然后选择获取源。
在手动和计划生成的默认分支下，更新功能分支。
选择保存并排队。
此管道成功运行后，使用正文中的有效 JSON 对 https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion> 执行 POST API 调用。现在应会收到 200 状态代码响应。

通过