一个接一个地触发管道
Azure DevOps Services |Azure DevOps Server 2022 |Azure DevOps Server 2020
大型产品具有多个相互依赖的组件。 这些组件通常独立生成。 当上游组件(例如库)发生更改时,必须重新生成和重新验证下游依赖项。
在这种情况下,请添加一个管道触发器,以在执行触发的管道成功完成后运行你的管道。
注意
之前,你可能已经导航到 YAML 管道的经典编辑器并配置 构建完成触发器 在用户界面中。 虽然该模型仍然有效,但不再推荐它。 建议的方法是在 YAML 文件中直接指定 管道触发器。 在经典编辑器中定义的生成完成触发器具有各种缺点,这些缺点现已在管道触发器中得到解决。 例如,无法使用生成完成触发器在与触发管道相同的分支上触发管道。
使用管道设置 UI 定义的触发器优先于 YAML 触发器。 若要从 YAML 管道中删除 UI 计划触发器,请参阅 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
指定此管道资源引用的管道的名称。 可以在多个位置(例如 Pipelines 登陆页)从 Azure DevOps 门户检索管道的名称。 默认情况下,管道以包含管道的存储库命名。 若要更新管道的名称,请参阅 管道设置。 如果管道包含在文件夹中,请包含文件夹名称,包括前导\
,例如\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 or greater.
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
阶段筛选器
注意
当触发管道的一个或多个阶段完成时,您可以使用 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
)。