31

我们最近从 SVN 迁移到了 git。我们使用主要的“发布”分支(主),以及开发人员正在处理的每个功能的功能分支。在TeamCity中,我们为每个功能分支都有一个项目,当然还有一个主项目。

当我们使用 SVN 时,每当有人从 master 合并到他的特性分支或反之亦然时,TeamCity 将合并视为一次提交。现在,使用 git,每次合并都会导致 TeamCity 显示此合并附带的所有提交。

这会导致一些问题,例如当某人从 master 合并到他的功能分支时,现在他的 TeamCity 项目由于该合并而显示“283 个未决更改”,如果构建失败,这些更改的作者将被通知,就好像他们做了一样功能分支上的这些更改。

有没有办法告诉 TeamCity 将 git 合并视为单一提交?

我们可以使用压缩合并来解决它,但这是我们真正想要避免的事情。

4

3 回答 3

27

我很确定这与我们几天前遇到的问题相同,反之亦然。我们将一个 dev 分支合并到 master 中,这导致 TC 尝试构建作为合并一部分的每个签入。显然不是我们想要的。

要修复它,请Trigger build on each check-inBuild Trigger.

您可以从源分支获取完整的更改历史记录,但 TeamCity 只会使用最新的合并代码构建目标分支。如果构建失败,合并应该是唯一通知的。

于 2012-12-21T15:48:19.243 回答
5

这是一个很长的镜头,您可能已经尝试过,但是将per check-in触发选项应用于 是否可行Include several check-ins in build if they are from the same committer?这可能足以诱使 TC 将提交构建为单个包。

于 2012-12-17T01:38:52.180 回答
3

这是两种可能的解决方案:

  1. 解决此问题的一种方法(尽管可能非常尴尬,取决于您的情况)是在构建配置级别通知用户,而不是通知谁提交/合并。为不同的主题分支创建单独的构建配置,并为每个构建配置配置通知,以便只通知主题分支的“所有者”。

  2. 不太确定,但值得一试:您可以为每个主题分支配置通知,例如通过分支路径上的通配符模式。这应该可以通过使用分支名称属性 teamcity.build.vcs.branch.<my_vcs_name>的 DYI自定义通知插件来实现。

TeamCity 电子邮件通知的一个特定限制(应该很容易支持)是您不能通过组合构建配置和“忽略不是由我的更改引起的失败”来过滤通知。然后至少您可以为主分支配置构建,以便通知提交者,并仅为主题分支项目创建特定设置。

于 2012-12-22T16:56:55.430 回答