编辑
在写下我的答案后，Microsoft 提出了另一种解决方案来解决此问题，即通过经典管道使用构建完成触发器。他们的解决方案可以在here找到。
如果您不从触发管道发布工件，它不会触发触发的管道。
此外，使用这些类型的触发器有很大的限制。需要将depends管道中的defaultBranch for manual and scheduled builds更改为工作分支。否则它不会在source 管道执行结束时启动。因此，假设您正在处理feature 分支，并且defaultBranch 设置为feature。你提交你的代码，一切都会按预期运行：source 管道启动，最后，depends 管道将被触发。都好！但是当你合并到master时，如果你不改变defaultBranch，depends管道不会在source管道结束时被触发。我在答案末尾解释了如何更改defaultBranch。
如何设置管道触发器
我设法在一个简约的项目中启动并运行它。 Here 你可以在 Azure DevOps 上获得代码和 here 项目。我将尝试指导您了解我是如何做到的，并回答您在帖子中提出的问题。
我将触发管道称为depends 管道，将触发管道称为source 管道。
在source 管道上，除了发布工件外，无需执行任何操作。如果您不从source 管道发布工件，它将无法工作。您可以在下面找到我用于我的虚拟source 管道的代码。我希望它为master 分支触发，最后我想确保发布一个工件。
trigger:
branches:
include: # branch names which will trigger a build
- master
pr: none
steps:
# required to cause pipeline triggering downstream
- task: CopyFiles@2
inputs:
contents: $(System.DefaultWorkingDirectory)/**/*.yml
targetFolder: $(Build.ArtifactStagingDirectory)
- task: PublishBuildArtifacts@1
inputs:
pathtoPublish: $(Build.ArtifactStagingDirectory)
artifactName: dummy-$(Build.BuildId)
在depends管道上（代码如下所示），我必须禁用CI和PR触发器，否则当我提交到这个repo时，这个管道会被CI触发器触发，然后在source 管道执行结束时。这是由我的代码的前两行完成的。然后我希望名为source 的管道（这是下面YAML 中的source 属性），在名为Pipelining 的项目中（YAML 中的project 属性）将触发当前的（depends）管道当此更新 master 分支时。
trigger: none
pr: none
resources:
pipelines:
- pipeline: source
project: Pipelining
source: source
trigger:
branches:
include:
- master
steps:
- checkout: none
- script: echo 'triggered depends'
这有意义吗？ Azure DevOps 上的项目名称必须与 YAML depends 管道代码中的 property 匹配。对我来说是 Pipelining
以及 source 属性，同样在 YAML depends 管道代码中。
更改default 分支
为了更改defaultBranch，由于上述问题，您应该编辑管道（在本例中为depends 管道），然后在右上角的三个点上选择Triggers .然后选择YAML选项卡，您将进入下图所示的屏幕，您可以在其中设置工作分支。