How to tell TeamCity to treat merges as a single commit when working with git?

31
votes

We recently moved from SVN to git. We work with a main "release" branch (master), and feature branches for every feature a dev is working on. In TeamCity we have a project for every feature branch, and of course a project for the master.

When we worked with SVN, whenever someone merged from master to his feature branch or vice-versa, the merge was treated by TeamCity as one commit. Now, with git, every merge causes TeamCity to show all of the commits that came with this merge.

This causes some problems, for example when someone merge from master to his feature branch, and now his TeamCity project shows "283 pending changes" due to that merge, if builds fail, the authors of these changes will be notified, as if they did these changes on the feature branch.

Is there a way to tell TeamCity to treat git merges as single commit?

We could solve it using squashed merges but that's something we would really like to avoid.

3
gitcontinuous-integrationteamcity
Can you just use git rebase? – Bartek Banachewicz
I'm not sure what you mean. We push our commits to a central repo, the one team city is listening to. We can't really rebase pushed changes, right? we kinda have to use merging. – yellowblood
Why do you want to avoid squashed merges? – Mark Leighton Fisher
Squashed merges aren't really merges, it will give us headaches like solving the same conflicts over and over again each time we try to (squash) merge from/to master. Am I right? – yellowblood
Yes – don’t do squashed merges. – Chronial

3 Answers

27
votes

I'm pretty sure this is the same issue that we had a few days ago, but vice-versa. We merged a dev branch into master, which caused TC to attempt to build each and every check-in that was part of the merge. Obviously not what we wanted.

To fix it, keep the Trigger build on each check-in option unchecked in the Build Trigger.

You get the full change history from the source branch, but TeamCity will only build the destination branch using the latest merged code. If that build fails, the merger should be the only one notified.

5
votes

This is a long shot, and you've probably already tried it, but might it work to apply the per check-in trigger option to Include several check-ins in build if they are from the same committer? This might be enough to trick TC into building the commits as a single bundle.

3
votes

These are two possible solutions:

  1. One way to solve this (though possibly very awkward, depending on your situation) is to notify users on the level of a build configuration as opposed to notifying who committed/was merged. Create separate build configurations for different topic branches and configure notification per build configuration so that only the 'owner' of the topic branch is notified.

  2. Less sure, but worth a try: You could configure notification per topic branch(es), e.g. by wildcard patterns on the branch path. This should be possible by means of a DYI custom notifier plug-in that uses e.g. the branch name property, teamcity.build.vcs.branch.<my_vcs_name>.

A specific limitation of TeamCity email notification (it should be easy to support) is that you can not filter notifications by a combination of build configuration and 'Ignore failures not caused by my changes'. Then at least you could configure the build for the main branch so that committers are notified, and create specific settings only for the topic branch projects.