问题 TeamCity构建Git / GitHub拉取请求

我们有一个TeamCity 7.1安装，可以从GitHub存储库构建所有分支。

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

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

一切都在游泳（经过大量搜索以获得正确的配置设置）然而......

上面的过程触发了TeamCity上的几个构建，我想知道它们是否都是必需的。通常我们最终会：

当然，第一个构建是特定分支上的最后一个签入，第二个构建是拉取请求，但是 什么是第三个构建？

3813

2017-09-28 06:04

起源

通常情况下这不是问题，但运行整个RoR测试套件并进行集成测试大约需要10分钟，因此我们不会在拉动请求中获得长达30分钟的构建状态反馈。 - asafb

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

TeamCity 7.1对自动触发器功能分支有一个非常好的功能，所以步骤（2）可以通过几次点击设置，像分支掩码一样 refs/heads/feature-*。

构建拉取请求没有任何意义，因为它们将由主构建覆盖。

2017-09-28 08:56

关于构建拉取请求，新的GitHub构建状态API允许我们直接在GitHub上显示拉取请求的构建状态，这是一个巨大的节省时间。当我们构建/ pulls / 1 / head分支时会出现这种情况。 - asafb

对于那些感兴趣的人，我们改变的关键设置之一是上面的分支规范（略微修改），和删除每次签到时的触发器构建导致我们大多数头痛的选项 - asafb

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

2017-11-20 11:44

这也意味着从master到pull请求分支的合并是多余的。 - Matt Gibson