Complex build dependencies and different branching models (specifically GitFlow)



We are using TeamCity with Stash and GitFlow

We have quite a complex dependency chain in TC with 20+ repositories that all produce artefacts that live in a dependant chain. We want to be able to change components without changing everything so certain repos can be branched and worked on while others are untouched. All my dependancies are using the "build from same chain" option.

We are running into difficulties with TCs branch support when dealing with all these dependencies and our branching model. difficulties like builds being a mixture of the wrong sources and the code coverage metrics comparing to the wrong branch. The default branch fall back doesn't seem to cut it.

EG; Builds A -> B -> ,C -> ,D. These are dependant on each other with A being the parent. (Our actual builds are more complex)

Scenario 1

We find a bug in live that requires a fix in Repo/Build B

So a developer creates a hotfix branch off from master in Repo B - The other repos are left at master in his dev environment. Codes the fix, tests it locally and commits.

TC builds B, and the chain then also builds A. But because Repo A doesn't have a corresponding hotfix branch it picks the default branch (in my case develop). This then creates an artefact that is a mixture of the wrong branches :( 

Scenario 2


Feature branches are taken from develop of Build A and features are gradually merged into develop for potential release. This work increases the code coverage on the develop branch for Build A over time.

We find a bug in live that requires another hotfix in Repo/Build A

Dev fixes and commits like before. TC builds fine this time because A is at the top of the chain, but then complains that the code coverage isn't high enough for the build. This is because its compared it to the last default branch build (develop). 

I really need a way to describe the branching model to the build/vcs root. Im currently having to build things manually by choosing the dependencies and also turning off coverage failure conditions.

Why not change the default branch?

Changing it to master would solve the two scenarios, but then cause us problems when we want to branch from develop to do our feature work. The same problems arise.


Has anyone run into this? Do you have any suggestions? I really dont want to create another buil, vcs root and dependency chain just to monitor the master/hotfix branches.

TC guys; Is there anything in the backlog to work on this as its a big problem for us? im surprised nothing has been said about it already - i did try to search but nothing came up.

Thanks in advance

Comment actions Permalink

Sorry to bump my own thread. But is there any advice on this?

Comment actions Permalink

Hello Justin,

Sorry for delay and thank you for the detailed description. The behavior is by design in both scenarios. 

  1. The builds in chain run on the same branch (logical branch name is used). If there is no branch with the same name in the build configuration, the default branch is checked out. Please see the section for more details.
    What behaviour do you expect in this case? On which branch build configuration A should be built?
  2. The same logic works for build failure conditions. If there is no suitable build on the same branch, then build from default branch is used.

> Changing it to master would solve the two scenarios, but then cause us problems when we want to branch from develop to do our feature work. The same problems arise.

Could you please elaborate? Why it does not work for you? 

Comment actions Permalink


I understand that this is by design. I also understand why it is doing what it is doing.

I guess i'm saying that the design of the software doesn't really meet my needs in terms of a GitFlow branching model and am asking for any advice on how to overcome this?

Changing it to master would solve those two scenarios.

But we have multiple teams working on these products at the same time. So while one team may be working on a hotfix off master (which requires the master branch to be the default). Another team might be working on a feature branch and need the default to be develop. 

Changing the default branch manually all the time would cause all projects to rebuild which takes time. It would also cause confusion between teams, id like teams to be able to commit and not have to worry about what TC is building

I need the default branch to change dynamically depending on which branch a developer commits to but i don't think that is possible?

I dont want to have to separate the builds and vcsroots so that master/hotfix/* is one vcsroot and develop/feature/* is another, but i'm starting to think this is the only way?


Does that explain things or am i still not making any sense? :) 




Comment actions Permalink

Thank you for the explanation.

It's not possible to configure several default branches in TeamCity or to change default branch dynamically. 

The recommended approach (as you suggested) is to create separate build configurations with different default branches. In case of dynamic branch switching it will be difficult to interpret the results of the builds. You should always check or remember on which branch the builds in chain run in different cases. It's make the logic less clear. In case of separate build configurations teams can just check the status of the configuration they are working on.

You can use build configuration templates with configuration parameters to simplify the setup.

Comment actions Permalink

Hi, sorry to resurrect an old thread but does TeamCity 10 do anything to help with this issue? 

I couldn't see anything in the patch notes but i just wanted to be sure.


Comment actions Permalink


No, there were no related fixes in TeamCity 10 version.


Please sign in to leave a comment.