TeamCity building Git/GitHub pull请求

我们有一个TeamCity 7.1安装程序，可以从GitHub存储库构建所有分支。TeamCity building Git/GitHub pull请求

GitHub有一个返回TeamCity的通知钩子来触发构建检查。我们还每隔120秒就有一次TeamCity轮询GitHub，以检查更改（如果检入更改时服务器处于脱机状态）。

我们的正常发展遵循一个共同的模式：

一切都在顺利运行（经过大量搜索以获得正确的配置设置），但是...

上述过程触发了TeamCity上的多个构建，我想知道它们是否都是必需的。通常，我们将结束：

当然第一个版本是最后一次检查，在特定的分支，第二个版本是拉请求，但w ^帽子是第三个构建？

2012-09-28 asafb

通常情况下，这不会是一个问题，但是使用集成测试运行我们的整个RoR测试套件需要大约10分钟，因此我们无法获得最多30分钟的拉取请求的生成状态反馈。 – asafb

您的构建看起来多余。组织TeamCity在git中构建功能分支的更节俭的方法如下：

TeamCity的7.1有一个非常好的功能来自动触发特征分支，所以步骤（2）可以是在一具有分支掩模像refs/heads/feature-*点击设置。

构建拉请求没有意义，因为它们将被主构建覆盖。

2012-09-28 08:56:24

关于构建pull请求，新的GitHub构建状态API允许我们直接在GitHub上显示拉取请求的构建状态，这是一个大规模的定时器。当我们构建/ pulls/1/head分支时会出现这个问题。 – asafb

对于那些有兴趣的人来说，我们改变的关键设置之一是上面的分支规范（稍作修改），**删除了导致我们大部分头痛的每个签入**选项的触发器构建 – asafb

第三次构建实际上是最有价值的 - 这是拉请求自动合并（发生合并，当你在github按下按钮时）的结果。

2012-11-20 11:44:31

这也意味着从主机合并到pull请求分支是多余的。 –

回答