如何在 Teamcity 中实现以下要求

Question

让我告诉你我们之前在 Jenkins 中想要做的事情。

a) 我们有构建和架构管道 (PMBD) 的通用存储库。

b) 当在 PMBD 存储库上创建拉取请求时，我们的上游管道会触发并检查更改的文件。

c) 如果提交或更新任何 .arxml 文件，那么它将触发架构管道作为其下游。

d) 如果提交或更新任何 .c 或 .h 文件，它将触发下游的构建管道。

e) 如果 .arxml 和 .c、.h 文件都被提交，那么它将触发构建和架构管道。

f) 如果提交了任何其他文件，它将跳过该构建。

g) 现在构建管道本身被视为上游作业，它将检查控制器列表（开发人员可以提到当前更新适用于 1 个或多个控制器），根据控制器列表，它将为每个控制器触发一个下游作业构建控制器。

h）因此，如果我们有 n 个控制器，则将触发 n 个下游作业，最后根据每个下游作业的构建结果，我们将向最终用户发送一封电子邮件，说明此控制器失败，而此控制器通过。

我想知道如何在 Teamcity 中实现相同的工作流程

Answer 1

您的设置相当复杂，我们不太可能构建整个解决方案来解决您在 StackOverflow 上的任务。

但无论如何，在执行此操作时，记住 Jenkins 和 TeamCity 之间的几个基本区别非常重要：

• Jenkins 的上游和下游构建概念被 TeamCity 中的快照和工件依赖关系所取代。它们可以形成构建链，其中最后的构建配置定义整个链所需的“状态”，并且参数可以在“上游”方向传播。一般来说，TeamCity 中的构建配置更像 Jenkins 中的管道阶段，构建链更像管道；
• 在 Jenkins 中，公共部分可以通过共享库或 JTE 重用。在 TeamCity 中，有模板（用于构建配置和项目）和元运行器（代表构建步骤并且可以组合多个步骤）。它们可以在项目和构建配置之间共享。此外，与 Jenkins 不同的是，TeamCity 允许定义在该项目内的所有构建配置之间共享的项目参数。整个项目配置可以在 TeamCity 中以声明方式（使用 Kotlin DSL）在代码中定义，而 Jenkins 只允许使用 JobDSL 生成文件夹和作业。