2

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

  • 集成 - 使用分支规范从开发、功能/* 和修补程序/* 构建
    • +:refs/heads/(开发)
    • +:refs/heads/feature/(*)
    • +:refs/heads/develop/(*)
    • +:res/heads/(热修复/*)

  • Beta - 从 beta/* 构建，带有分支规范

    • +:refs/heads/(释放/*)

  • 发布 - 从具有分支规范的 master 构建

    • +:refs/heads/(master)

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

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

更新-附加信息 这是“违规构建”的概述 在此处输入图像描述 这是触发器配置 在此处输入图像描述

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

我已经尝试在 JetBrains 支持论坛上提出这个问题，但我似乎没有在那里获得任何牵引力，所以我想我会联系 StackOverflow 社区。

4

1 回答 1

1

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

于 2015-05-05T19:02:45.253 回答