11

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

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

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

  1. 从 master 创建一个分支
  2. 提交到该分支，直到完成一个功能
  3. 完成后，从 master 拉取以合并任何更改并推送到远程
  4. 提交 GitHub 拉取请求以允许管理员合并到 master

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

上述过程触发了 TeamCity 上的几个构建，我想知道它们是否都是必要的。通常我们会得到：

  • /refs/heads/分支名称的构建
  • /refs/pull/ number /head的构建
  • /refs/pull/ number /merge的构建

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

4

3 回答 3

13

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

于 2012-11-20T11:44:31.267 回答
3

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

  1. 组织refs/heads/master分支的持续集成。120 秒的投票在这里是相当合理的。
  2. refs/heads/feature-name为每个分支组织夜间构建。根据我的经验，只有少数功能分支需要 120 秒的轮询。

TeamCity 7.1 有一个非常好的自动触发功能分支的功能，所以步骤 (2) 可以通过点击几下设置，如refs/heads/feature-*.

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

于 2012-09-28T08:56:24.407 回答
0

更新答案，以防有人仍在使用 TeamCity

自 2018 年以来，有一个原生的Pull Request Build Feature。与使用分支触发器和过滤器相比，这是一个更好的解决方案，因为它在构建和相应的 PR 之间创建了双向链接，并且使您不必向refs/pull/...VCS 分支规范添加任何内容。

尽管如此，如果您坚持使用pull/*/merge：请注意，如果在 GH 存储库上启用了“需要线性历史记录”（=仅允许从 PR 合并 Rebase 和 Squash）功能，则会创建多余的构建，因为在这种情况下 PR 只能是无论如何，一旦它与它的基本分支是最新的，它就会合并。

于 2020-11-11T07:54:56.887 回答