Complex build dependencies and different branching models (specifically GitFlow)
Hi,
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
Please sign in to leave a comment.
Sorry to bump my own thread. But is there any advice on this?
Hello Justin,
Sorry for delay and thank you for the detailed description. The behavior is by design in both scenarios.
What behaviour do you expect in this case? On which branch build configuration A should be built?
> 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?
Hi,
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? :)
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.
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.
Thanks
Hello,
No, there were no related fixes in TeamCity 10 version.