使用 Git 触发 TeamCity 非确定性构建答案

【问题标题】：TeamCity non-deterministic build triggering with Git使用 Git 触发 TeamCity 非确定性构建
【发布时间】：2015-07-15 13:58:19
【问题描述】：

我使用 GitFlow 分支策略。我喜欢每个项目有 3 个构建配置：

集成 - 使用分支规范从开发、功能/* 和修补程序/* 构建
- +:refs/heads/(develop)
- +:refs/heads/feature/(*)
- +:refs/heads/develop/(*)
- +:res/heads/(hotfix/*)
Beta - 从 beta/* 构建，带有分支规范
- +:refs/heads/(release/*)
Release - 从具有分支规范的 master 构建
- +:refs/heads/(master)

注意使用括号来设置我喜欢的分支名称。我有这 3 个构建的原因是因为我使用构建配置名称作为构建名称的一部分，所以例如我得到格式为 1.2.3-Integration.27 的构建，最终数字“27”是项目范围的共享构建计数器。我还在不同的配置中采取不同的构建后操作，例如发布配置执行部署操作。

作为我所说的“非确定性”的一个例子，我刚刚通过拉取请求将功能分支合并到了开发中。我在我的集成构建配置中获得了一个构建，它构建了开发分支。但是随后我也得到了其他两个构建配置的构建，即使它们的分支规范中没有任何变化；这绝对不是我想要的，因为我的发布配置，例如，部署的东西。这是突出显示有问题的构建的屏幕截图：

更新 - 附加信息 这是“违规构建”的概述这是触发器配置

我显然不了解 TeamCity 应该如何与 Git 一起工作。我的印象是构建配置只应该构建属于其分支规范的东西。另外两个是哪里来的？当分支规范不包含开发（或参考/头/开发）时，为什么会触发这些构建？有没有办法阻止这种情况发生？

我尝试在 JetBrains 支持论坛上提出这个问题，但我似乎没有在那儿获得任何关注，所以我想我应该联系 StackOverflow 社区。p>

【问题讨论】：

标签： git teamcity git-flow buildconfiguration

【解决方案1】：

如果您有一个随时触发更改的构建触发器，您将获得此行为。我的项目中有一个非常相似的设置，我通常在触发器构建部分指定所有分支规范。

【讨论】：

感谢您的回复 - 已发布请求的其他详细信息。如果我对您的理解正确，您是否建议我需要在触发器中指定分支再次？如果是这样，那么分支规范的用途是什么？
分支规范可以很好地覆盖命名约定（就像您在括号中为选择较短的分支名称所做的更改一样）。当谈到分支规范时，有一些陷阱，我确实对在分支规范选项卡中选择或过滤的内容有自己的疑问（例如，默认分支，总是选择开发）。然而，触发器规范精确到一个点，并且更适合选择/过滤特定分支。如果我不清楚，请随时回复
我明白你的意思...我的构建配置都继承自一个通用模板，我尝试尽量减少配置之间的差异，我希望分支规范就足够了。我猜不会！好吧，如果构建工作正常，我想要付出很小的代价。我对它进行了一些试验，但我的触发过滤器似乎无法正常工作。我想知道您是否能够提供一个触发器过滤器与您的一个构建中的分支规范的示例？（当然，如有必要，匿名）。
我很长时间以来都试图让 TC 屈服，但无论我尝试什么，它都会在每一个转折点上打败我。例如，如果要在 VC 触发器上设置分支过滤器，则不能将其作为模板的一部分！最后，我放弃了触发器中的分支过滤器，回到只使用分支规范，我在每个构建配置中将其设置为配置参数。我通过创建一个名为 NoBuild 的虚拟分支并使 that 成为默认分支来解决“开发”（即 默认分支）会在任何地方触发的事实。讨厌的黑客，但它的工作原理。