TeamCity本地项目CI集成：如何配置跨项目联动构建链

不要强行合并两个项目的.teamcity配置文件，用TeamCity原生能力即可实现需求，完全保留两个项目配置与自身代码库的版本关联，不需要做路径映射这类hack操作。

基础方案（推荐，90%场景适用） #

核心思路是不改动两个项目原有独立构建配置，通过跨项目构建链+快照依赖实现触发和逻辑复用：

• 保留项目A、B原有独立配置结构：两个项目各自维护自身代码库根目录下的.teamcity/settings.kts和对应构建逻辑，TeamCity服务端的两个项目条目分别绑定各自VCS根，正常同步配置即可，不需要迁移任何配置，完全保留配置和代码的版本绑定关系。
• 在项目B下新建独立的「B-A兼容性测试」构建配置，不要修改B原有正式构建链的逻辑：
  • 给该配置添加两个VCS根：第一个是项目B的常规VCS根，开启代码变更自动触发，检出目录设为B；第二个是项目A master分支对应的VCS根，关闭自动触发规则，检出目录设为A。
  • 给该配置添加两个快照依赖：第一个依赖指向B的最新成功正式构建，第二个依赖指向A master分支的最新成功构建，两个依赖都勾选「不重新构建依赖项，如果有符合条件的成功构建直接复用」，同时关闭A侧依赖的反向触发，避免A的代码变更误触发B的集成测试。
• 构建步骤直接复用两个项目原有逻辑，不需要重复写构建脚本：
  1. 进入B目录，执行B项目原有的构建、打包命令，产出本次变更的B构建物
  2. 调整依赖引用规则：如果是本地源码依赖，直接在A的构建配置里把B的依赖地址指向本次工作区的B构建产物路径；如果是私服依赖，第一步先把B的构建产物发布到团队私服的临时快照版本，A构建时拉取该版本即可
  3. 进入A目录，执行A原有的全量构建、集成测试命令，验证B的变更是否兼容A的master分支逻辑

这个方案没有冗余配置，两个项目的构建逻辑还是各自维护，改A的构建逻辑不需要动B的配置，改B的也不会影响A，维护成本最低。

特殊场景方案（需要复用A的DSL配置逻辑时用） #

如果确实需要在B的构建配置里直接复用A项目.teamcity/kotlin_code里定义的Kotlin DSL逻辑，不需要做检出规则的路径映射，直接用TeamCity Kotlin DSL原生的跨VCS加载配置能力即可，在B的settings.kts里直接写：

// 直接从A的master分支VCS根加载指定的DSL脚本，不需要手动检出文件到工作区
applyFrom(vcsRootId = "VCS_ROOT_ID_OF_A_MASTER", path = ".teamcity/kotlin_code/your-reuse-script.kt")

TeamCity在同步配置阶段会自动拉取对应VCS路径下的脚本内容加载，不会污染构建代理的工作区目录，也不需要手动维护配置文件的拷贝逻辑。

不推荐之前两种设想的原因 #

• 手动检出A的配置到B目录做合并：会导致配置来源混乱，后续A更新构建逻辑时需要同步修改路径映射规则，维护成本高，容易出现配置版本和代码版本不匹配的问题
• 把所有TeamCity配置抽到独立仓库：完全割裂了配置和项目代码的版本关联，切历史版本代码的时候无法匹配到对应版本的构建配置，排查历史问题成本极高

内容的提问来源于stack exchange，提问作者Takoda