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