How to set parameters for Automatic merge Build Feature dynamically?

Hi everybody,

I'm struggling with the Automatic merge Build Feature.

I'm trying to set the source and destination branches for the automatic merge dynamically. To achieve this, I've added a build step which sets environment variables depending on the current branch.

Overriding the environment variables seems to work - they have the expected values in the subsequent build steps.

For some reason, the Automatic merge Build Feature ignores the updated variables. There are always the initial values (which I set to "dummy"). The build fails with "no VCS branch maps to the 'dummy' logical branch name".

Could anyone tell me what I'm doing wrong? Or is it simply not possible to override parameters for Build Features dynamically?

Thank you very much in advance.

Kind regards


The build step which sets the environment variables looks like this:


    'releases/1.0 integration/master'
    'integration/master master'
echo "Currently on branch: $branch"

for branchstr in "${branches[@]}"
    read -a arr <<<$branchstr
    if [ ${arr[0]} == $branch ]

if [ -z ${targetbranch+x} ]
    echo "no target branch found"
    echo "target branch: $targetbranch"
    echo "##teamcity[setParameter name='env.SOURCE_BRANCH' value='$branch']"
    echo "##teamcity[setParameter name='env.TARGET_BRANCH' value='$targetbranch']"


In the Automatic merge Build Feature I refer to the variables like this:


Comment actions Permalink

Hi Ronald,

TeamCity resolves all references with the available parameters before starting a build. If there are references that cannot be resolved, they are left as is and a warning will appear in the build log.
When you use service messages the changed build parameters will be available in the build steps following the modifying one, however it's not replaced in the build feature.

Could you please describe the behavior you try to archive? Perhaps it's possible to configure it in another way.
Comment actions Permalink

Hi Alina,

Thank you for your response.

What I'm trying to achieve is what's described here in the section at the bottom where it says "Cascading Merge":

The problem:

We have a lot release branches which we want to merge cascadingly (approx. 5). If I get it right, we would need quite a lot build configurations to achieve the cascading merge through all branches.

To be more precisely:

Let's call our 5 release branches:

  • releases/1.0
  • releases/2.0
  • releases/3.0
  • releases/4.0
  • releases/5.0

Additionally, there's one integration branch per release branch (except of releases/1.0) plus one for the master:
  • integration/2.0
  • integration/3.0
  • integration/4.0
  • integration/5.0
  • integration/master

The merge should cascade as follows automatically:

releases/1.0 -> integration/2.0 -> releases/2.0 -> integration/3.0 -> releases/3.0 -> integration/4.0 -> releases/4.0 -> integration/5.0 -> releases/5.0 -> integration/master -> master

If I get it right, we would need 10 build configurations to achieve this (if the target branch cannot be set dynamically). Am I right? Or is it possible with significantly less build configurations?

Thank you very much in advance for your help.

Kind regards,

Comment actions Permalink


I have the same issue that Roland with the version 2019. Do you have any plan to support this feature?

Comment actions Permalink

Hi Marc-andre, 


I think there was a misunderstanding with Roland. In order to do the cascading merge he explained he wouldn't need 10 build configurations, just 1. Simply add the "Automatic merge" feature 10 times and set up a chain of merges from the different releases to master. An example I just tested using the DSL:

features {
        merge {
            branchFilter = "+:refs/heads/cascading-2"
            destinationBranch = "%defbranch%"
        merge {
            branchFilter = "+:refs/heads/cascading-3"
            destinationBranch = "refs/heads/cascading-2"
        merge {
            branchFilter = "+:refs/heads/cascading-4"
            destinationBranch = "refs/heads/cascading-3"


This applies 3 different merges, when a commit arrives at cascading-4, it is merged into cascading-3. This triggers a VCS trigger as well, which runs on -3 and the merge merges automatically onto -2, which repeats merging into %defbranch%. Parameter references are supported but can only be overridden on triggering. Could you share the use case for the need to override them at runtime? 


Please sign in to leave a comment.