Azure Devops的存储库中有100多个服务/应用程序。我们为每个（构建和部署）定义了一个CI / CD YAML多级管道。这限制了爆炸半径，并允许对每个项目的每个版本进行审核。我们依靠模板来完成所有实际的管道工作，因此易于维护；对于每个包含所需模板的项目，它只是一个小的根azure-pipelines.yml根文件。
现在，我们想开始使用PR验证版本。而且，据我所知，我们有两个选择：
我不喜欢第一个选项，因为现在我们将拥有200多个版本。第二个选项是可能的，但是要避免3小时的PR构建，我们需要一种仅运行所需阶段（又称为项目构建）的方法。
我是否缺少第三种选择？如果第二选项是我们最好的选择，那么我们如何关闭该PR中未更改的项目的阶段（即我们将使用哪种条件）？
（仅供参考，我们的政策是每个PR只能更改一个项目，但是有时会有例外。）
答案 0 :(得分：1)
对于个人建议，我也建议第二种方法。尽管在一个配置文件中构建脚本会非常大，但比起数百个构建配置文件要好得多。
但是困难在于这100多个应用程序全部集中在一个存储库中。这意味着所有常规方法都不适合您，包括使用Build.Repository.Name值作为阶段条件。同样，没有更多的细节描述提交中存储的源文件路径。
因此，我建议您和您的团队开发人员在您的提交消息中输入project name信息。然后，在构建管道中，您可以使用变量Build.SourceVersionMessage来获取其注释消息。由于这是仅只能在步骤级别中使用的环境变量（不适用于阶段级别和职位级别 ），则需要在第一步中添加一个任务并为其使用条件。
其逻辑是在每个阶段的第一个步骤中添加一个步骤。此步骤仅用于条件判断。如果Build.SourceVersionMessage与前缀或任何关键内容单词匹配，则作业将提前退出。
如果使用以下条件：
condition: startsWith(variables['Build.SourceVersionMessage'], '[maven-plugin]')
需要您的提交消息必须遵循严格的内容编写格式，从指定的项目名称开始。
您可以考虑的另一种情况是：
condition: in(variables['Build.SourceVersionMessage'], 'maven-plugin')
这不需要严格的内容编写格式，但是还需要在提交消息中输入项目名称。因此，可以使用上述脚本在工作条件下对其进行评估。
希望它能为您提供帮助。