views:

207

answers:

2

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.

A: 

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

Vladimir
A: 

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

adymitruk
I know I could have used git log -p ..origin/master there but find the 'not' syntax more expressive
adymitruk