Teamcity only trigger tags from one branch

Question

My team is using TeamCity for CI and i am kinda new to it.

We are using git tags to help out with versioning, however i've come into one problem.

So far i managed to make it so when a new tag is created a build in TeamCity triggers, however the problem is it triggers for any branch and any tag. Is there a way to make builds trigger only when TAGS are created on a SPECIFIC BRANCH?

I only want a build to trigger when a tag is created on master branch.

Thank you for help.

Answer 1

The tags as objects in Git are not tied to any specific branch - they are just pointed to certain revisions. Tags can even point to those revisions which are not part of any branch (detached HEAD). Hence, I suspect that it is technically challenging for TeamCity to judge whether Git tag is created in the branch to monitor or not.

However, you can work it around by establishing some naming rules for Git tags. For example, tags created on master branch should be called release/something or main/something . In this case, the value in the Branch specification field can be narrowed down to +:refs/tags/release/* .

Answer 2

It's usually simpler to trigger builds for any commit to a branch, rather than using tags in this way. For example, in gitflow the only commits to master should be merges that represent new releases, so if you used that convention you could simply monitor master to trigger builds.

If you want to use tags, there are really two options.

The easy option is to use naming conventions on your tags, as Yan Sklyarenko suggests. Of course, it's possible for someone to put the wrong tag in the wrong place, which is either a feature (it's flexible) or a bug (mistakes lead to wasted production builds). And there's an element of "hidden magic" going on there. But it is an easy-to-implement option at least.

The harder way to do more-or-less directly what you're asking, is to trigger a build on any tag, but then include a build step that aborts unless that tag is found to be "on the master branch".

Now I put "on the master branch" in quotes because, as Mr. Sklyarenko points out, it's speaking a bit loosely about how branches and tags are structured in git. Really you would say, you want to know about new tags that are "on commits reachable from master ". And in fact, you probably mean "reachable from master using first-parent pointers only". That is to say

       D
      / \
A -- B - E -- F <--(master)
 \
  C <--(branch)

If we tag C , this is not reachable from master . ("Reachable" means via parent pointers, so you can only follow lines leftward on the diagram.)

D is reachable from master , but if things were done "normally" D is the second parent of E . So if we say "reachable by first-parent pointers", then A , B , E , and F qualify - and that's probably what you mean by "on master ".

The only way I know to do that kind of check in TC is by having a scripted build step; so then you need a git command that will provide the information, does this tag meet the criteria? You could use this:

git rev-list --first-parent master |grep -q $(git rev-parse <tagname>)

(where <tagname> is the name of the tag) which will return 0 iff the tag meets the criteria.

Given how you're using tags, you might also want to check that the tag in question is the latest tag on master . That is, if you have

A -- B -- C -- D <--(master)
          ^
          tag-1.0

you might want to build only if someone tags D , not if they tag A , B , or C (since you already have a tag at C ). In that case, you could check whether

git describe --tags --first-parent --abbrev=0 master

returns the name of your new tag.