16
votes

I have several projects that produce NuGet packages that I publish to an internal server. We're using semantic versioning, and using tags in our Git repository to control the version numbers.

I'm tagging like this:

git tag -a v1.0.0 -m "tagged"

And, during the TeamCity build, I run git describe --long, which produces an output like this:

v1.0.0-0-ge9c047d

The fourth number in the output is the number of commits after the tag. The 0 here means that no commits have been made since the tag. I use these first four numbers as the version number (and, incidentally, the entire string as the AssemblyInformationalVersion).

I have TeamCity package and publish a NuGet package, but here's where it gets sticky. I only want to publish tags, never commits after tags (because the version number in that case would be wrong, possibly VERY wrong).

I've tried setting the "branch specification" in the VCS root to "+:refs/tags/*", which causes all the tags to be built, but TeamCity also insists on building the "default branch" as well. If I set the "default branch" to something that doesn't exist, I get an error.

I've thought about ending the build early if a particular build isn't a tag, but I can't figure out how to do that without FAILING the build, which isn't what I want.

How do I cause one or more build steps to only run for new tags, and not regular commits?

1

1 Answers

15
votes

If you are using TeamCity 8.x, there is now support for VCS branch triggers, which would allow you to not run builds from the default branch.

Try this:

  1. Leave the Branch Specification in the VCS Root as "+:refs/tags/*"
  2. Change the VCS build trigger rules to:

    +:*

    -:<default>

This will filter out the default branch from the trigger and you won't need to cancel the build.