TeamCity中GitLab合并请求触发构建功能异常排查求助

看起来你在配置TeamCity + GitLab合并请求触发构建时遇到了挺头疼的问题——开第一个MR没反应，开第二个反而触发第一个的构建，这种情况我之前帮朋友排查过，大概率是配置里的几个细节冲突导致的，我帮你拆解下可能的原因和调整方案：

1. VCS根分支规范不全，TeamCity识别不到MR分支 #

你当前的VCS根分支规范只配置了:my_build_settings_branch，这就导致TeamCity只会拉取这个特定分支的代码，完全没包含GitLab合并请求对应的分支引用格式（refs/merge-requests/*/*）。TeamCity连MR的分支都识别不到，自然没法正常触发构建。

调整方案：
把VCS根的分支规范改成：

+:refs/heads/*
+:refs/merge-requests/*/*

这样TeamCity就能覆盖到所有分支以及GitLab上的合并请求分支，才能正确监听MR的相关事件。

2. 同时配置PR Provider和手动VCS触发器，触发逻辑冲突 #

你现在的构建配置代码里同时做了两件事：

• 配置了GitLab PR Provider（pullRequests代码块），这是TeamCity官方推荐的MR触发方式，本身就会自动监听GitLab的MR创建、更新事件
• 又通过trigger参数控制添加了一个额外的VCS触发器

这两个触发逻辑叠加在一起，很容易出现识别混乱，就是你遇到的“开MR2反而触发MR1构建”的核心原因。

调整方案：
直接删掉那个通过trigger参数控制的VCS触发器代码块（就是从val trigger = ...到triggers { ... }的所有内容），完全依赖PR Provider的自带触发能力就足够了，不需要额外手动加VCS触发器。

3. PR配置里的分支过滤细节修正 #

• 你定义targetBranch时用了trimIndent()，可能会引入不必要的空格，建议直接写成简洁的字符串常量：

  val targetBranch = "+:refs/heads/master"
  

• 确认filterTargetBranch = targetBranch符合你的需求：这个配置是只允许目标分支为master的MR触发构建，如果你确实只想触发合并到master的MR，这个是对的，但要检查你创建的MR的目标分支是不是确实是master，别选错了分支。
• 留意ignoreDrafts = true：如果你的MR被标记为草稿状态，会被TeamCity忽略，检查下你之前开的MR是不是不小心设成了草稿。

4. 验证GitLab Token的权限和有效性 #

• 确保你配置的MY_TOKEN在GitLab项目里有足够的权限：至少需要read_api权限，这样TeamCity才能读取到项目的合并请求事件。
• 可以在TeamCity的构建配置页面，找到GitLab PR Provider的配置项，点击“测试连接”，确认TeamCity能正常和GitLab通信。

5. 最后做个小验证 #

调整完所有配置后，先手动运行一次构建，确认TeamCity能正常拉取到MR的代码，然后再新建一个MR测试触发逻辑，看看是否能正常触发对应的构建。

内容来源于stack exchange