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

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开发者_如何学JAVA 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.

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

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