一个接一个地触发管道

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

• YAML 管道
• 经典管道

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

在这种情况下，请在成功完成触发管道后，添加一个管道触发器来运行管道。

注意

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

配置管道资源触发器

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

以下示例配置一个管道资源触发器，以便在完成 security-lib-ci 管道的任何运行后运行名为 app-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 指定此管道资源引用的管道的名称。 可以在 Azure DevOps 门户中的多个位置（例如 Pipelines 登陆页）检索管道的名称。 默认情况下，管道与包含该管道的存储库同名。 若要更新管道名称，请参阅管道设置。 如果管道包含在文件夹中，请包含文件夹名称，其中包括前导 \（如 \security pipelines\security-lib-ci）。
• project: FabrikamProject - 如果触发管道位于另一个 Azure DevOps 项目中，则你必须指定项目名称。 如果源管道和被触发管道位于同一项目中，则此属性是可选的。 如果你指定此值并且管道未触发，请参阅本部分末尾的注释。
• trigger: true - 使用此语法在源管道的任何版本完成时触发管道。 请参阅本文中的以下部分，了解如何通过筛选来查看完成哪些源管道版本会触发运行。 指定筛选器后，源管道运行必须与所有筛选器匹配才能触发运行。

如果触发管道和被触发管道使用同一存储库，则当一个管道触发另一个管道时，两个管道都将使用相同的提交来运行。 如果第一个管道生成代码，第二个管道测试代码，则这种状态很有帮助。 但是，如果两个管道使用不同的存储库，则被触发管道将使用由 Default branch for manual and scheduled builds 设置指定的分支中的代码版本，如管道完成触发器的分支注意事项中所述。

注意

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

YAML 模板不支持配置管道完成触发器。 你仍然可以在模板中定义管道资源。

分支筛选器

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

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

若要为触发父级的不同分支触发子管道，请包括为其触发父级的所有分支筛选器。 在以下示例中，如果 security-lib-ci 在任何 releases/* 分支或主分支上完成（releases/old* 除外），则 app-ci 管道就会运行。

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

注意

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

标记筛选器

注意

管道资源的标记筛选器支持需要 Azure DevOps Server 2020 Update 1 或更高版本。

trigger 的 tags 属性筛选出以下结果：哪些管道完成事件可以触发你的管道。 如果触发管道与 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 属性用于确定在手动或通过计划触发器触发管道时，要从中检索工件的管道运行。 有关详细信息，请参阅资源：管道和评估工件版本。

阶段筛选器

注意

管道资源触发器的阶段筛选器需要 Azure DevOps Server 2020 Update 1 或更高版本。

使用 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 触发器匹配的推送，并且完成与管道完成触发器的筛选器匹配的源管道的运行时，预期都可以启动新的运行。

例如，假设名为 A 和 B 的两个管道位于同一存储库中，两者都有 CI 触发器，B 具有为管道 A 完成配置的管道完成触发器。 如果向存储库发出推送：

• 基于 A 的 CI 触发器启动它的新运行。
• 同时，基于 B 的 CI 触发器启动它的新运行。 此运行将使用管道 A 的上一个运行中的工件。
• A 完成后，它会基于 B 中的管道完成触发器触发 B 的另一个运行。

若要防止在此示例中触发 B 的两个运行，必须禁用其 CI 触发器 (trigger: none) 或管道触发器 (pr: none)。