Share via

在 YAML 中定义资源

  • 项目

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

YAML 中的资源表示管道、生成、存储库、容器、包和 Webhook 的源。 资源还提供管道中使用的服务（包括版本、生成工件、关联的提交和工作项）的完全可跟踪性。 定义资源时，可以在管道中的任意位置使用资源。 此外，可以通过订阅资源上的触发事件来完全自动执行 DevOps 工作流。

有关详细信息，请参阅关于资源和资源 YAML 架构定义。

架构

resources:
  pipelines: [ pipeline ]  
  builds: [ build ]
  repositories: [ repository ]
  containers: [ container ]
  packages: [ package ]
  webhooks: [ webhook ]

变量

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

resources.triggeringAlias
resources.triggeringCategory

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

定义 pipelines 资源

如果有生成生成工件的管道，可以通过定义 pipelines 资源来使用生成工件。 pipelines 是仅适用于 Azure Pipelines 的专用资源。 还可以在 CD 工作流的管道资源上设置触发器。

在资源定义中，pipeline 是一个唯一值，稍后可以使用该值来引用管道资源。 source 是生成了生成工件的管道的名称。 使用 pipeline 定义的标签引用其他管道部分的管道资源，例如使用管道资源变量或下载生成工件时。

有关下载管道的替代方法，请参阅管道工件中的任务。

resources:        # types: pipelines | builds | repositories | containers | packages
  pipelines:
  - pipeline: string  # identifier for the resource used in pipeline resource variables
    project: string # project for the source; optional for current project
    source: string  # name of the pipeline that produces an artifact. If it is in a different pipelines folder, it needs to be the full path, e.g. MyTeam/MyPipeline
    version: string  # the pipeline run number (Build.BuildNumber) to pick the artifact, defaults to latest pipeline successful run across all stages; Used only for manual or scheduled triggers
    branch: string  # branch to pick the artifact, optional; defaults to all branches; Used only for manual or scheduled triggers
    tags: [ string ] # list of tags required on the pipeline to pickup default artifacts, optional; Used only for manual or scheduled triggers
    trigger:     # triggers aren't enabled by default unless you add trigger section to the resource
      branches:  # branch conditions to filter the events, optional; Defaults to all branches.
        include: [ string ]  # branches to consider for the trigger events, optional; Defaults to all branches.
        exclude: [ string ]  # branches to discard the trigger events, optional; Defaults to none.
      tags: [ string ]  # list of tags to evaluate for trigger event, optional
      stages: [ string ] # list of stages to evaluate for trigger event, optional

重要

定义资源触发器时，如果其管道资源来自当前管道所在的同一存储库（例如，自存储库），则触发将遵循引发事件的同一分支和提交。 但是，如果管道资源来自不同的存储库，则当前管道将在自存储库的默认分支上触发。

生成工件版本的评估

资源管道工件的版本取决于管道的触发方式。

如果管道因手动触发或计划运行而运行，则生成工件的版本由 version、branch 和 tags 属性的值定义。

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

接下来举例说明。 假设管道包含以下资源定义。

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main      ### This branch input cannot have wild cards. It is used for evaluating default version when pipeline is triggered manually or scheduled.
    tags:               ### These tags are used for resolving default version when the pipeline is triggered manually or scheduled
    - Production        ### Tags are AND'ed
    - PreProduction

手动触发管道运行时，MyCIAlias 管道的生成工件版本是 main 分支上完成具有 Production 和 PrepProduction 标记的最新生成之一。

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

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

接下来举例说明。 假设管道包含以下资源定义。

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

每当 SmartHotel-CI 管道在其中一个 releases 分支或 main 分支上运行，标记为 Verified 和 Signed，并且完成了 Production 和 PreProduction 阶段时，管道就会运行。

管道的 download

将自动下载当前管道和所有 pipeline 资源中的所有生成工件，并在每个 deployment 作业开始时提供。 可以替代此行为。 有关详细信息，请参阅管道工件。 不会自动下载常规的“作业”生成工件。 在需要时显式使用 download。

steps:
- download: [ current | pipeline resource identifier | none ] # disable automatic download if "none"
  artifact: string ## artifact name, optional; downloads all the available artifacts if not specified
  patterns: string # patterns representing files to include; optional

将 pipeline 资源中的生成工件下载到 $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier> 文件夹。

管道资源变量

在每个运行中，管道资源的元数据可供采用预定义变量形式的所有作业使用。 <Alias> 是你为管道资源指定的标识符。 管道资源变量仅在运行时可用。

若要了解有关变量语法的详细信息，请参阅定义变量。

resources.pipeline.<Alias>.projectID
resources.pipeline.<Alias>.pipelineName
resources.pipeline.<Alias>.pipelineID
resources.pipeline.<Alias>.runName
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

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

定义 builds 资源

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

resources:        # types: pipelines | builds | repositories | containers | packages
  builds:
  - build: string   # identifier for the build resource
    type: string   # the type of your build service like Jenkins, circleCI etc.
    connection: string   # service connection for your build service.
    source: string   # source definition of the build
    version: string   # the build number to pick the artifact, defaults to Latest successful build
    trigger: boolean    # Triggers aren't enabled by default and should be explicitly set

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

重要

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

生成的 downloadBuild 任务

可以使用 downloadBuild 任务来使用 build 资源中的生成工件作为作业的一部分。 根据定义的 build 资源的类型，此任务在运行时自动解析为服务的相应下载任务。

将 build 资源中的生成工件下载到 $(PIPELINE.WORKSPACE)/<build-identifier>/ 文件夹。

重要

build 资源生成工件不会自动下载到 jobs/deploy-jobs 中。 需要显式添加 downloadBuild 任务以使用生成工件。

- downloadBuild: string # identifier for the resource from which to download artifacts
  artifact: string # artifact to download; if left blank, downloads all artifacts associated with the resource provided
  patterns: string | [ string ] # a minimatch path or list of [minimatch paths](tasks/file-matching-patterns.md) to download; if blank, the entire artifact is downloaded

定义 repositories 资源

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

resources:
    repositories:
    - repository: string # Required as first property. Alias for the repository.
      endpoint: string # ID of the service endpoint connecting to this repository.
      trigger: none | trigger | [ string ] # CI trigger for this repository, no CI trigger if skipped (only works for Azure Repos).
      name: string # repository name (format depends on 'type'; does not accept variables).
      ref: string # ref name to checkout; defaults to 'refs/heads/main'. The branch checked out by default whenever the resource trigger fires.
      type: string # Type of repository: git, github, githubenterprise, and bitbucket.

类型

管道支持存储库类型的以下值：git、github、githubenterprise 和 bitbucket。 git 类型引用 Azure Repos Git 存储库。

指定的类型 业务成效 示例
type: git name 值引用同一项目中的另一个存储库。 name: otherRepo 若要引用同一组织内另一个项目中的存储库，请在名称前面加上该项目的名称。 示例为 name: OtherProject/otherRepo。
type: github name 值是 GitHub 存储库的全名，并且包括用户或组织。 name: Microsoft/vscode
type: githubenterprise name 值是 GitHub Enterprise 存储库的全名，并且包括用户或组织。 name: Microsoft/vscode
type: bitbucket name 值是 Bitbucket 云存储库的全名，并且包括用户或组织。 name: MyBitbucket/vscode

GitHub Enterprise 存储库需要 GitHub Enterprise 服务连接进行授权。

Bitbucket 云存储库需要 Bitbucket 云服务连接进行授权。

变量

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

resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.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

使用 checkout 来使用存储库

使用 checkout 关键字来使用定义为 repository 资源一部分的存储库。

架构

steps:
- checkout: string # Required as first property. Configures checkout for the specified repository.
  clean: string # If true, run git clean -ffdx followed by git reset --hard HEAD before fetching.
  fetchDepth: string # Depth of Git graph to fetch.
  fetchTags: string # Set to 'true' to sync tags when fetching the repo, or 'false' to not sync tags. See remarks for the default behavior.
  lfs: string # Set to 'true' to download Git-LFS files. Default is not to download them.
  persistCredentials: string # Set to 'true' to leave the OAuth token in the Git config after the initial fetch. The default is not to leave it.
  submodules: string # Set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules. Default is not to fetch submodules.
  path: string # Where to put the repository. The default is $(Build.SourcesDirectory).
  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.

repository 资源中的存储库不会在作业中自动同步。 使用 checkout 提取存储库作为作业的一部分。

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

定义 containers 资源

如果需要使用容器映像作为持续集成/持续交付 (CI/CD) 管道的一部分，可以使用 containers 来实现。 容器资源可以是公共或专用 Docker 注册表，也可以是 Azure 容器注册表。

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

resources:
  containers:
  - container: string  # identifier (A-Z, a-z, 0-9, and underscore)
    image: string  # container image name
    options: string  # arguments to pass to container at startup
    endpoint: string  # reference to a service connection for the private registry
    env: { string: string }  # list of environment variables to add
    ports: [ string ] # ports to expose on the container
    volumes: [ string ] # volumes to mount on the container
    mapDockerSocket: bool # whether to map in the Docker daemon socket; defaults to true
    mountReadOnly:  # volumes to mount read-only - all default to false
      externals: boolean  # components required to talk to the agent
      tasks: boolean  # tasks required by the job
      tools: boolean  # installable tools like Python and Ruby
      work: boolean # the work directory

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

可以将第一类容器资源类型用于 Azure 容器注册表 (ACR) 来使用 ACR 映像。 此资源类型可用作作业的一部分，还可用于启用自动管道触发器。 需要具有 ACR 的参与者或所有者权限，才能使用自动管道触发器。 有关详细信息，请参阅 Azure 容器注册表角色和权限。

resources:          # types: pipelines | repositories | containers | builds | packages
  containers:
  - container: string # identifier for the container resource      
    type: string # type of the registry like ACR, GCR etc. 
    azureSubscription: string # Azure subscription (ARM service connection) for container registry;
    resourceGroup: string # resource group for your ACR
    registry: string # registry for container images
    repository: string # name of the container image repository in ACR
    trigger: # Triggers aren't enabled by default and need to be set explicitly
      enabled: boolean # set to 'true' to trigger on all image tags if 'tags' is unset.
      tags:
        include: [ string ]  # image tags to consider the trigger events, optional; defaults to any new tag
        exclude: [ string ]  # image tags on discard the trigger events, optional; defaults to none

注意

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

注意

azureSubscription 不支持使用工作负荷联合身份验证的服务连接。

容器资源变量

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

容器资源变量适用于 Docker 和 Azure 容器注册表。 不能将容器资源变量用于本地映像容器。

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

位置变量仅适用于容器资源的 ACR 类型。

定义 packages 资源

可以使用 NuGet 和 npm GitHub 包作为 YAML 管道中的资源。

指定 package 资源时，请将包设置为 NuGet 或 npm。 还可以在发布新的包版本时启用自动化管道触发器。

若要使用 GitHub 包，请使用基于个人访问令牌 (PAT) 的身份验证，并创建使用 PAT 的 GitHub 服务连接。

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

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConnectionName # GitHub service connection with the PAT type
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.1 # Version of the package to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

定义 webhooks 资源

注意

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

借助其他资源（如管道、容器、生成和包），可以使用生成工件并启用自动触发器。 但是，不能基于其他外部事件或服务自动执行部署过程。 利用 webhooks 资源，可以将管道与任何外部服务集成，并自动执行工作流。 可以通过其 Webhook（GitHub、GitHub Enterprise、Nexus、Artifactory 等）订阅任何外部事件，并触发管道。

执行以下步骤来配置 Webhook 触发器。

  1. 在外部服务上设置 Webhook。 创建 Webhook 时，需要提供以下信息：

    • 请求 URL

      https://dev.azure.com/<ADO Organization>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview

    • 机密 - 可选。 如果需要保护 JSON 有效负载，请提供密钥值。

  2. 创建新的“传入 Webhook”服务连接。 此连接是新引入的服务连接类型，可用于定义以下重要信息：

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

    传入 Webhook 服务连接

  3. YAML 管道中引入了名为 webhooks 的新资源类型。 若要订阅 Webhook 事件，请在管道中定义 Webhook 资源，并将其指向传入 Webhook 服务连接。 还可以基于 JSON 有效负载数据在 Webhook 资源上定义更多筛选器，以自定义每个管道的触发器。 在作业中以变量的形式使用有效负载数据。

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

resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias           ### Webhook alias
      connection: IncomingWebhookConnection    ### Incoming webhook service connection
      filters:                                 ### List of JSON parameters to filter; Parameters are AND'ed
        - path: JSONParameterPath              ### JSON path in the payload
          value: JSONParameterExpectedValue    ### Expected value in the path provided

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

“创建运行”对话框中资源的手动版本选取器

手动触发 CD YAML 管道时，我们会根据提供的输入自动评估管道中定义的资源的默认版本。 但是，在创建运行时，可以选择从资源版本选取器中选取不同的版本。

  1. 在创建运行窗格中，选择资源。 你将看到此管道中使用的资源列表。

  2. 选择一个资源，并从可用版本列表中选取特定版本。 管道、生成、存储库、容器和包资源支持资源版本选取器。

    管道版本选取器

对于管道资源，可以查看所有分支中的所有可用运行。 根据管道编号或分支搜索运行。 然后，选取成功、失败或正在进行的运行。 这种灵活性可确保你能够运行 CD 管道（如果你确定它生成了所需的所有生成工件）。 无需等待 CI 运行完成或重新运行，因为 CI 运行中出现不相关的阶段故障。 但是，仅当我们评估计划触发器的默认版本时，或者不使用手动版本选取器时，才会考虑成功完成的 CI 运行。

对于无法提取可用版本的资源（如 GitHub 包），我们会显示一个文本框作为版本选取器的一部分，以便你可以为运行提供版本以供选取。

授权 YAML 管道

必须先对资源进行授权，然后才能使用资源。 资源所有者控制可以访问该资源的用户和管道。 必须授权管道使用资源。 请参阅授权 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 模板扩展。 设置所需的模板审批可增强安全性。 确保资源仅在特定条件下使用模板。 详细了解如何使用模板和资源增强管道安全性。

可跟踪性

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

管道可跟踪性

对于每个管道运行，我们都会显示以下信息。

  • 触发管道的资源（如果管道由资源触发）。

    管道中的资源触发器

  • 所用资源和生成工件的版本。

    管道运行中已使用的生成工件

  • 与每个资源关联的提交。

    管道运行中的提交

  • 与每个资源关联的工作项。

环境可跟踪性

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

环境中的提交

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

若要提供端到端可跟踪性，可以跟踪哪些 CD 管道正在使用给定 CI 管道。 可以看到 CD YAML 管道运行的列表，其中 CI 管道运行通过 pipeline 资源使用。 如果其他管道使用 CI 管道，运行视图中会显示“关联的管道”选项卡。 可在此处找到使用管道的所有管道运行以及其中的生成工件。

CI 管道中的 CD 管道信息

YAML 资源触发器问题支持和可跟踪性

当管道触发器无法执行时，可能会令人困惑。 我们在管道定义页中添加了名为触发器问题的新菜单项，可在其中了解触发器不执行的原因。 若要访问此页，请打开管道历史记录。 触发器问题仅适用于非存储库资源。

从导航中选择“触发器问题”。

资源触发器可能由于以下原因而无法执行。

  • 如果所提供的服务连接的源无效，或者触发器中存在任何语法错误，则不会配置触发器，从而导致错误。

  • 如果触发器条件不匹配，则不会执行触发器。 将显示一条警告，以便你可以了解条件不匹配的原因。

    触发器问题可支持性

后续步骤

添加和使用变量组

常见问题解答

为什么应使用管道 resources 而不是 download 快捷方式？

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

可以选择在生成作业中下载生成工件，或使用 download 替代部署作业中的下载行为。 有关详细信息，请参阅 steps.download。

为什么应使用 resources 而不是“下载管道工件”任务？

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

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

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

  1. 创建新的 Docker Hub 服务连接。

  2. 创建经典发布管道并添加 Docker Hub 生成工件。 设置服务连接。 选择命名空间、存储库、版本和源别名。

    添加 Docker Hub 生成工件。

  3. 选择触发器并将持续部署触发器切换为“启用”。 每当对所选存储库执行 Docker 推送时，就会创建一个发布。

  4. 创建新阶段和作业。 添加两个任务：Docker 登录和 Bash：

  • Docker 任务具有 login 操作并登录到 Docker Hub。

  • Bash 任务运行 docker pull <hub-user>/<repo-name>[:<tag>]。 将 hub-user、repo-name 和 tag 替换为你自己的值。

    添加 Docker 登录和 Bash 任务。

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

  1. 创建服务连接。

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

    resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias
      connection: MyServiceConnection

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

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