Option to consider labelling as a part of build

Hi all,

I believe I got a change request here. Would it be possible to create such an option that TeamCity will consider labelling as a final step during successful build? As I found from online documentation here TeamCity considers labelling as an additional step it can do after the build was reported.

Problem with current approach is that if your VCS is slow at labelling (and our ClearCase takes may be 10-30 minutes to put a label for some of projects!) someone can start making use of a label before TeamCity completes labelling. And this activity isn't transactional, so if TeamCity dies you'll have only part of your source code labelled. That I would like to consider as a build failure. So current design posses a host of problems for us.

I'd appreciate any feedback on that matter.

Thank you!

Best regards,

Comment actions Permalink


While possible, the feature will be not so easy to implement. Currently the labeling process occurs on the server-side, so in order to implement this request we will need to add one more build stage "post-build steps on the server-side". And the build will still be running in the case, so the agent will still be assigned to the build.

I'd suggest you to file a feature request in the tracker and let's see how popular it will be. For the time being I would consider creating the label from the build script.

Comment actions Permalink

Yegor, the idea was to be able to repeat the build be it success or failure. If you don't put a label on the source code you are unlikely to be able to repeat it.

And because labelling is time consuming operation within our ClearCase setup it is important to provide clear indication on is the label ready to be used or not. Build status can be such an indication, however there could be another field on the build page that lists labels applied to the build source code and any status of labelling process that may be currently at the time when the user checks the build status. Something like that.

But after some considerations and review of our build processes I see that we can do without labelling at all if we use TeamCity as CI tool only rather than CI + build server tool. And indeed TeamCity isn't ready to present itself as a build server because I don't see how someone can start a build of labelled source code. Guess it doesn't have such function.

And about build script. With ClearCase I doubt it will be possible to put a label on source code from the build script in your distributed environment where build agents are independent from the server and can be running elsewhere.

Hope it helps where I came from. Now I believe labelling is something you don't need to do at all in CI scenario.

Comment actions Permalink


The latest EAP release already has the feature to start a build on any change known to TeamCity.

BTW, without using labels, can't you use the sources revision displayed on the Changes tab in the "VCS revisions and labels" table?
The table also displays thew status of sources labeling.

Can you please detail what features you consider mandatory for a "build server"?

Comment actions Permalink

Hi Yegor,

I noticed this Time Machine feature, but I think you are approaching the task from the wrong side.

One of the most important features for the "build server" is to enable repeatable builds. Means if you built something not so long ago you have means to repeat the build and receive exactly the same results. You should assume that if IT Audit comes and wants to validate some build against version control system you should demonstrate that binaries would be exactly the same (at least so far as actual business logic is concerned). Your time machine does the job, but it is very TeamCity specific and I doubt it is realistical to assume any long-term project will decide to adopt it. Instead most use source code labels to indicate which versions were part of the build and then they have means to build exactly that versions. That's the function of the build server.

Going further if you expect TeamCity to make it into mainstream you should assume that it doesn't live in isolation and there is an enterprise landscape to integrate with already. For an example, it may be necessary to upload build artifacts to some shared drive on remote server or put them into version control system. And it is not a task of the build script really nor should it be a manual task.

Another requirement would be Disaster Recovery. If you got TeamCity as your main build server, how would you recover it after hardware failure? Loss of data center? Mind 9/11 kind of "incident". There should be a procedure that documents which files and how often must be replicated to DR server to enable smooth recovery. I didn't really search for such information on your WIKI though, but I doubt you got it there already.

TeamCity GUI is very good and it is something you can build upon.


Comment actions Permalink

I agree,

Builds based only on sources and current state of the SCM are not sufficient.
Teamcity should be able to get sources for a specific label, and run from this label.
Of course this can be done by scripting, but it makes complex, things that should be easy.

In our environment we have a build that creates some artifacts that are used later by a another build that's testing these artifacts and we would like to put a label on the sources only if this second build is successful.


Please sign in to leave a comment.