Confusion about Triggered Builds


I am hoping that someone can help with the current issue that I am facing.  Here is what I have...

I have recently set up a Stash, JIRA, TeamCity and Octopus Deploy Development Environment.  In addition, we are trying to adopt the GitFlow methodology for branching.  On the whole, things seems to be working the way that I would expect them to, with one exception.

First though, let me tell you what I have configured in TeamCity.

I have three build configurations.  

The first is setup to trigger on every commit into a feature, release, or hotfix branch.  That way, developers can work in "isolation" on a feature, and still get the benefit of Continuous Integration builds.  In addition, we are using a TeamCity Plugin which reports the build status back to Stash.
The second is setup to trigger on every change to a pull request branch.  We are using Pull Requests within Stash to accept all work from feature, release and hotfix branches.
The third is setup to trigger on any commits into develop or master branch, and has a snapshot dependency on the second build, and it is responsible only for the deployment of the artifacts to Octopus Deploy.

Does anyone see a problem with the above approach?  I have been through a few iterations of the above, but to me, it seems to make sense.

The problem that I am having is to do with the following workflow...

  1. Raise an issue in JIRA, let's say GEP13
  2. Create a local branch in git called feature/GEP13, using current develop branch as base point
  3. Do the necessary work in this branch to implement the feature, lets say 3 commits worth
  4. Push the local branch to Stash
  5. Go into Stash UI and see that there is only 3 of commits in this branch, compared to develop
  6. Go to TeamCity and expect to see only 3 queued builds (i.e. one for every commit), since VCS Trigger is set up to trigger on every change
  7. Actually see that there are over 40 queued builds!!

TeamCity seems to be taking every change in the new feature/GEP13 branch since the start of the repository, and executing a build for each one?!?  This really isn't what I would like.  What I would like is obivously for TeamCity to only have three queued builds.  Then assuming that the result of these builds are successful, I would then go into Stash and create a Pull Request from feature/GEP13 into develop, which would trigger the second build configuration.  And assuming that went ok, and the Pull Request was approved, the work would be done to merge the Pull Request into develop, which would then trigger the third build configuration.

Can anyone suggest whether the problem is in my TeamCity configuration, or in Stash?

Do you require any further information in order to help out?



Comment actions Permalink

Can you post the VCS Trigger configuration here, too? Also, how does the VCS root configuration look like? (more specifically, branch specification)

Comment actions Permalink

Hello Maarten,

Thanks for getting back to me!

Here is my VCS Trigger Configuration:

And the branch specification in the VCS Root looks like the following:


What I am trying to do in this build configuration is to limit triggered builds to ONLY come from a Feature, Release, or Hotfix branch, and to force a build for every commit.  However, what I seem to be getting is a build for every commit in the history of the newly created branch, rather than ONLY the commits on that branch.

I have just tried with the "Trigger a build on each check-in" option off, and as expected, I only got one build triggered, but this included 112 changes:


What I would like, is a build for each of the commits shown in Stash:


Is this possible?



Comment actions Permalink

The VCS Trigger is configured to trigger a build for any check-in in any branch right now, which seems to mimic the behaviour you are seeing. It will trigger a new build for any change, anywhere in the repo and for every check-in separately.

Can you try copying the branch specification from the VCS root into the VCS Trigger's filter? That will change the trigger to only start a build for feature, hotfix and release branches.

Comment actions Permalink

Ok, that seems to have done something! :-)

I changed the Branch Filter of the VCS Trigger to be the following:


And having added two commits to the GSA-37 branch, I can now see the correct number of pending changes:


But now the build never gets triggered :-(

Did I do the wrong thing?  Should the branch specifications be exactly the same in both the VCS Root and the VCS Trigger?


Comment actions Permalink

In the current branch filter, the exclusions aren't really needed, as they don't match the VCS root branch specification anyway.

The VCS trigger should work now, what interval is it set to? It may take a bit before the build actually starts because of the "Quiet period mode" setting on the trigger.

Comment actions Permalink

I have waited quite a while now, over 15 minutes, and the build still isn't triggered, so I "think" that this is outwith any quiet period that might be holding it open.

Would this have anything to do with the "logical" branch name, described here:

In my branch filter, I currently have this:


but the branch names are actually the following when displayed in TeamCity:


So, should be branch filter actually contain something like:


If so, how do I set up the branch filter, because I specifically don't know the name of the feature branch.  They will always start with GSA*, since this is the JIRA prefix that we are using, but having a branch filter of:


feels a bit "dirty" :-)

Comment actions Permalink

You could try +:* or as you say, +:GSA-*

Comment actions Permalink

Doesn't using +:* not take me back to the beginning though?!?

From where you told me to move away from, since it would then trigger on everything?

Comment actions Permalink


You should specify logical branch name when configure Branch filter in VCS Trigger. For more details about how branch name is configured please read this section.
If you set branch filter +:* then according to attached branch specification trigger will listen to branches refs/head/feature/*, refs/head/hotfix/*, refs/head/release/*. While trigger will not listen to other branches, which are not mentioned in branch specification.

Comment actions Permalink

Hello Alina,

As Maarten has point out, the linked issue on YouTrack held the answer to the problem that I was having.

Thank you everyone for your help!



Please sign in to leave a comment.