TeamCity and pending Git merge branch commit keeps build with failed tests

Question

We use TeamCity for continuous integration and Git for source control. Generally it works pretty well - convenient, modern and good us quick feedback when tests fails.

There is a strange behavior related to Git merge specifics. Here are steps of the case:

1. First developer pulls from master repo.
2. Second developer pulls from master repo.
3. First developer makes commit A locally.
4. Second developer makes commit B locally;
5. Second developer pushes commit B.
6. First developer want to push commit A but unable because he have to pull commit B first.
7. First developer pull's from remote reposity.
8. First developer pushes commit A and generated merge branch commit.

The history of commits in master repo is following:

• B second developer
• A first developer
• merge branch first developer.

Now let's assume that Second Developer fixed some failing tests in his commit B.

What TeamCity will do is following:

1. Commit B arrives - TeamCity makes build #1 with all tests passed

2. Commit A arrives - TeamCity makes build #2 (without commit B) test bar becomes Red!

3. TeamCity thought that Pending "Merge Branch" commit doesn't contain any changes (any new files) - but it actually does contain the merge of commit B, so the TeamCity don't want to make new build here and make tests green.

Here are two problems: 1. In our case we have failed tests returning back in second commit (commit A) 2. TeamCity don't want to make a new build and make tests back green.

Does anybody know how to fix both of this problems.

I consider some reasonable general approach.

Answer 1

Is not yet fixed in 5.0.3. But it's reported as known issue

You can vote for this issue at http://youtrack.jetbrains.net/issue/TW-9584

Answer 2

Just to add, I strongly advise on using git pull --rebase, or entirely just do a git fetch then do a revision of what has changed with git log -p ^master origin/master to determine if I'm ok with what happened due to other devs' work. At this point I can rebase my work on top of the remote changes and teamcity will not give you the problems you see here. This is not something I do to work around teamcity but is also part of a workflow that allows a more linear history and merge conflict resolutions that you do not have to revisit if you are merging previous merges.

HTH,

Adam