Automatic merge before build


This has been discussed in numerous posts before, and there's a feature request at

But in addition to this, I want to discuss if it's possible to achieve this without resorting to command line merge or waiting for the feature request to get some traction.

So, is it possible to write a plugin that would handle the pre-build merge instead of using the command line? If so, where should I start looking? My first guess is that this might have to be a VCS plugin, meaning that I'd have to fork the existing git plugin, unless there's some sort of a "extend a plugin" mechanism.

To elaborate:

We have setup where we have 3 related projects  (application A, configurator B, test framework C) with  a "git flow" type of branching setup, which are gathered together in a nightly attempt to merge their respective development branches to their master branches. Basically the test framework uses the configurator to configure the application, then flashes it on to hardware and executes a bunch of tests that take anywhere between 4 to 30 hours.

The development branches of these are built on commit, but for the test run I'll have to make a special "integration build" which does the pre-build merge, so I get the proper binaries to use in the actual test run.

Ideally I'd also like the build history to show that a build is indeed an "integration build": instead of showing "refs/heads/develop" as the built branch, it'd show something like "refs/heads/develop applied on top of refs/heads/master", since that is the actual case.

This last point can be worked around by using two different build jobs, but it'd still leave the build history in a misleading state as it would always say that the test builds are run on refs/heads/develop, even though they are actually refs/heads/master with develop on top.

Any pointers?


Hey Dmitry,

Thanks for the reply.

Your suggestion is probably what I'll end up doing if I can't figure out the plugin approach in a reasonable way.

The only drawback is the misleading history which I figured I might be able to fix in the plugin approach, but I'm not at all certain that it's worth the effort.


I'm not sure I understand why the history would be misleading. Could you please clarify that?


Maybe I misunderstood you, or have some other fundamental misunderstanding here, but as far as I'm aware the merge builds must be triggered by the 'source' branch, which would be integration in the case of your example.

Now, if I do a rebase on top of master as a build step, what's actually being built will not be the head of integration, even though that's what TeamCity will show in the history since that is what triggered the build, right?


Could you please clarify why do you need to rebase on top of master? I thought that in gitflow people don't commit directly to master, they merge their develop branch into master once it is ready. If all commits make it into master through develop branch, then there is no need to rebase, no?


Yes, for proper git-flow you're correct. However ours is sadly "git-flow-esque". The largest difference being that with PM approval stuff will end up in master without going through develop.

Probably the solution to this is to convince people to change the process, instead of trying to work around it. Maybe just use release branches that are merged back into develop and then to master for those "last minute" fixes.

I'll try your approach and get back to you with how it works out. Might be that these are simply non-issues.


Please sign in to leave a comment.