触发一个接一个的管道

Azure DevOps Services |Azure DevOps Server 2022 |Azure DevOps Server 2020

大型产品具有多个相互依赖的组件。 这些组件通常独立生成。 当上游组件(例如库)发生更改时,下游依赖项必须重新生成并重新验证。

在此类情况下,请添加管道触发器,以在触发管道成功完成后运行 管道

注意

以前,你可能已导航到 YAML 管道的经典编辑器,并在 UI 中配置了 生成完成触发器 。 虽然该模型仍然有效,但不建议再使用。 建议的方法是直接在 YAML 文件中指定 管道触发器 。 经典编辑器中定义的生成完成触发器具有各种缺点,这些缺点现已在管道触发器中得到解决。 例如,无法使用生成完成触发器在与触发管道相同的分支上触发管道。

配置管道资源触发器

若要在另一管道完成后触发管道,请配置 管道资源 触发器。

以下示例配置管道资源触发器,以便名为 的 app-ci 管道在管道的任何运行 security-lib-ci 完成后运行。

此示例具有以下两个管道。

  • security-lib-ci - 此管道首先运行。

    # security-lib-ci YAML pipeline
    steps:
    - bash: echo "The security-lib-ci pipeline runs first"
    
  • app-ci - 此管道有一个管道资源触发器,该触发器将 app-ci 管道配置为在每次管道运行完成时自动运行 security-lib-ci

    # app-ci YAML pipeline
    # We are setting up a pipeline resource that references the security-lib-ci
    # pipeline and setting up a pipeline completion trigger so that our app-ci
    # pipeline runs when a run of the security-lib-ci pipeline completes
    resources:
      pipelines:
      - pipeline: securitylib # Name of the pipeline resource.
        source: security-lib-ci # The name of the pipeline referenced by this pipeline resource.
        project: FabrikamProject # Required only if the source pipeline is in another project
        trigger: true # Run app-ci pipeline when any run of security-lib-ci completes
    
    steps:
    - bash: echo "app-ci runs after security-lib-ci completes"
    
  • - pipeline: securitylib 指定管道资源的名称。 从管道的其他部分引用管道资源时(例如,在使用管道资源变量或下载项目时),请使用此处定义的标签。
  • source: security-lib-ci 指定此管道资源引用的管道的名称。 可以在多个位置(例如 Pipelines 登陆页)从 Azure DevOps 门户检索管道的名称。 默认情况下,管道以包含管道的存储库命名。 若要更新管道的名称,请参阅 管道设置
  • project: FabrikamProject - 如果触发管道位于另一个 Azure DevOps 项目中,则必须指定项目名称。 如果源管道和触发的管道位于同一项目中,则此属性是可选的。 如果指定此值且管道未触发,请参阅本部分末尾的备注。
  • trigger: true - 使用此语法在源管道的任何版本完成时触发管道。 请参阅本文中的以下部分,了解如何筛选完成的源管道的哪些版本将触发运行。 指定筛选器后,源管道运行必须与所有筛选器匹配才能触发运行。

如果触发管道和触发的管道使用相同的存储库,则当一个管道触发另一个时,这两个管道将使用相同的提交运行。 如果第一个管道生成代码,第二个管道对其进行测试,这非常有用。 但是,如果两个管道使用不同的存储库,则触发的管道将使用 设置 Default branch for manual and scheduled builds 指定的分支中的代码版本,如 管道完成触发器的分支注意事项中所述。

注意

在某些情况下,手动生成和计划生成的默认分支不包含 refs/heads 前缀。 例如,默认分支可能设置为 main ,而不是 设置为 refs/heads/main。 在此方案中, 来自不同项目的触发器不起作用。 如果在设置为 project 目标管道以外的值时遇到问题,可以通过将默认分支的值更改为其他分支,然后将其更改回要使用的默认分支来更新为包含 refs/heads

分支筛选器

可以选择性地指定要在配置触发器时包括或排除的分支。 如果指定分支筛选器,则每当与分支筛选器匹配的源管道运行成功完成时,就会触发新管道。 在以下示例中app-ci,如果 在除 之外releases/old*的任何releases/*分支上完成,security-lib-ci则管道将运行。

# app-ci YAML pipeline
resources:
  pipelines:
  - pipeline: securitylib
    source: security-lib-ci
    trigger: 
      branches:
        include: 
        - releases/*
        exclude:
        - releases/old*

注意

如果分支筛选器不起作用,请尝试使用前缀 refs/heads/。 例如,使用 refs/heads/releases/old*而不是 releases/old*

标记筛选器

tags筛选器的 属性,trigger管道完成事件可以触发管道。 如果触发管道与列表中的所有标记 tags 匹配,则管道将运行。

resources:
  pipelines:
  - pipeline: MyCIAlias
    source: Farbrikam-CI
    trigger:
      tags:        # This filter is used for triggering the pipeline run
      - Production # Tags are AND'ed
      - Signed

注意

管道资源还具有 tags 属性。 tags管道资源的 属性用于确定手动或由计划的触发器触发管道时,要从中检索项目的管道运行。 有关详细信息,请参阅 资源:管道项目版本的评估

阶段筛选器

可以使用 筛选器在触发管道的一个或多个阶段完成时触发 stages 管道。 如果提供多个阶段,则触发的管道将在所有列出的阶段完成时运行。

resources:
  pipelines:
  - pipeline: MyCIAlias  
    source: Farbrikam-CI  
    trigger:    
      stages:         # This stage filter is used when evaluating conditions for 
      - PreProduction # triggering your pipeline. On successful completion of all the stages
      - Production    # provided, your pipeline will be triggered. 

分支注意事项

管道完成触发器使用 手动生成和计划生成的默认分支 设置来确定 YAML 管道分支筛选器的哪个分支版本在确定是否作为另一个管道完成的结果运行管道时进行评估。 默认情况下,此设置指向存储库的默认分支。

管道完成后,Azure DevOps 运行时会评估任何管道的管道资源触发器分支筛选器,其中包含引用已完成管道的管道完成触发器。 一个管道在不同的分支中可以有多个版本,因此运行时在 设置指定的分支中评估管道版本中的 Default branch for manual and scheduled builds 分支筛选器。 如果存在匹配项,则管道将运行,但运行的管道版本可能位于不同的分支中,具体取决于触发的管道是否与已完成的管道位于同一存储库中。

  • 如果两个管道位于不同的存储库中,则运行 指定的分支中触发的 Default branch for manual and scheduled builds 管道版本。
  • 如果两个管道位于同一存储库中,则会运行与触发管道相同的分支中的触发管道版本,即使该分支不同于 Default branch for manual and scheduled builds,并且即使该版本没有与已完成管道的分支匹配的分支筛选器也是如此。 这是因为分支中的分支筛选器 Default branch for manual and scheduled builds 用于确定是否应运行管道,而不是完整管道分支中版本中的分支筛选器。

如果管道完成触发器似乎未触发,请检查默认分支的值,以获取已触发管道的 手动和计划生成 设置。 该分支版本的管道中的分支筛选器用于确定管道完成触发器是否启动管道运行。 默认情况下, Default branch for manual and scheduled builds 设置为存储库的默认分支,但可以在创建管道后对其进行更改。

管道完成触发器不会触发的典型方案是,创建新分支时,管道完成触发器分支筛选器会修改为包含此新分支,但当第一个管道在与新分支筛选器匹配的分支上完成时,第二个管道不会触发。 如果分支中管道版本中 Default branch for manual and scheduled builds 的分支筛选器与新分支不匹配,则会发生此情况。 若要解决此触发器问题,可以使用以下两个选项。

  • 更新分支中管道中的 Default branch for manual and scheduled builds 分支筛选器,使其与新分支匹配。
  • 手动和计划生成的默认分支 设置更新为具有与新分支匹配的分支筛选器的管道版本的分支。

组合触发器类型

在管道中同时指定 CI 触发器和管道触发器时,每次进行与 CI 触发器筛选器匹配的推送时,都可能会启动新的运行,并且完成与管道完成触发器的筛选器匹配的源管道运行。

例如,假设同一存储库中有两个名为 AB 的管道,它们都有 CI 触发器,并且 B 为完成管道 配置了管道 A完成触发器。 如果推送到存储库:

  • 将基于其 CI 触发器启动 的新运行 A
  • 同时,会根据其 CI 触发器启动 的新运行 B 。 此运行使用上一次管道 A运行中的项目。
  • 完成后A,它会根据 中的B管道完成触发器触发的另一个运行B

若要防止在此示例中触发的两次 B 运行,必须删除其 CI 触发器或管道触发器。