YAML 管道中的资源

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

管道项目版本评估

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

手动或计划触发器

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

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

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

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

重要

仅当 Azure DevOps 与 Jenkins 服务器有视线时，托管 Jenkins 才支持触发器。

downloadBuild 任务

不会build在作业/部署作业中自动下载资源项目。 若要将资源中的项目 build 用作作业的一部分，需要显式添加 downloadBuild 任务。 可以为每个部署或作业自定义下载行为。

此任务会自动解析为运行时定义的资源类型的 build 相应下载任务。 资源 build 中的项目将下载到 $（PIPELINE）。WORKSPACE）/<build-identifier>/ folder。

在定义中 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.repository.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
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和resourceGrouprepository值。 例如：

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

注意

不支持使用工作负荷标识联合azureSubscription的服务连接。

容器资源变量

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

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

以下示例具有一个名为 arm-connectionAzure 资源管理器 服务连接。 有关详细信息，请参阅 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指定包<存储库>/<名称>，并将包type设置为NuGet或 npm。 若要使用 GitHub 包，请使用基于个人访问令牌（PAT）的身份验证，并创建使用 PAT 的 GitHub 服务连接。

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

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

以下示例具有一个名为 GitHub npm 包contoso的 pat-contoso GitHub 服务连接。 有关详细信息，请参阅 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 中发布。

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

webhooks YAML 管道中的资源允许将管道与 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 触发管道，请向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 管道使用资源。

• 使用资源管理体验授权 所有管道 访问资源。 例如，变量组和安全文件在管道下的“库”页中管理，代理池和服务连接在 Project 设置中管理。 如果不需要限制对资源的访问（例如测试资源），则此授权很方便。

• 创建管道时，如果这些资源具有 “用户 ”角色，则 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 管道信息

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

资源触发器问题

资源触发器可能无法执行，因为：

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

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

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

常见问题解答

何时应使用管道资源、下载快捷方式或下载管道项目任务？

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

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

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

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

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

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

如何验证和排查 Webhook 问题？

1. 创建服务连接。

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

   resources:
     webhooks:
       - webhook: MyWebhookTriggerAlias
         connection: MyServiceConnection
   

3. 运行管道。 Webhook 在 Azure 中创建为组织的分布式任务。

4. 使用正文中的有效 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 ...，则代码可能位于不是默认分支的分支中。 若要解决此问题：

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

相关内容

• 关于 Azure Pipelines 的资源
• 定义变量
• 添加和使用变量组
• 创建环境并以该环境为目标
• 使用 YAML 管道编辑器
• YAML 架构参考