Borland StarTeam "Build Labels"

Hello,

I'm trying out TeamCity v4.0.2 with Borland StarTeam.

I am wondering about labelling options for Borland StarTeam.

If I look under a project's configuration version control Settings, I see I am allowed to automatically label a build under "VCS labeling mode".  I tried this out and it creates what StarTeam calls a "view label".  This is what I was hoping for.

What I was also hoping for was a way to control whether or not the view label is what StarTeam calls a "build label" (when creating a label through the StarTeam GUI it shows "use as build a label" as a checkbox field) .  It seems that TeamCity always creates view labels that are also build labels.  I would rather that this not be the case.  Any way to control that somewhere?

Much thanks,

-Lee-

10 comments
Comment actions Permalink

Hello Lee,

Currently all labels created by TeamCity are "build labels". This behavior
is hardcoded since it seems to be natural in respect of how it's used in
TeamCity. I mean what TeamCity labels is actually a build. So making this
label a "build label" looks quite consistent.

Could you please explain the point of making this behavior optional?

Thank you.

Hello,

I'm trying out TeamCity v4.0.2 with Borland StarTeam.

I am wondering about labelling options for Borland StarTeam.

If I look under a project's configuration version control Settings, I
see I am allowed to automatically label a build under "VCS labeling
mode". I tried this out and it creates what StarTeam calls a "view
label". This is what I was hoping for.

What I was also hoping for was a way to control whether or not the
view label is what StarTeam calls a "build label" (when creating a
label through the StarTeam GUI it shows "use as build a label" as a
checkbox field) . It seems that TeamCity always creates view labels
that are also build labels. I would rather that this not be the case.
Any way to control that somewhere?

Much thanks,

-Lee-

---
Original message URL:
http://www.jetbrains.net/devnet/message/5231903#5231903

--
Sergey Anchipolevsky
Software Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Thanks for your reply Sergey,

We are only looking at introducing a continuous build system to our processes now, it could very well be that old habits are clouding my thinking.  That said:

StarTeam has an integrated defect tracking system.  If a label is marked as "use as a build label" then the label is made available to the StarTeam defect tracking system and anyone can log defects against the build label. It is typically our quality control team that log defects.

In the past, we've only created "build labels" when we release to our quality control team.

My thinking was that our quality control team would become confused with the many extra build labels that a continuous build system would produce.  I like the idea of labeling all builds, but am not crazy about exposing all of them to our defect tracking system.

-Lee-

0
Comment actions Permalink

Hello Lee,

Thank you for the explanation. Now I understand your concern.

We can implement this to be a configurable option.
At which level would you prefer to have it?

1. Global - switch it on/off for the whole server;
2. VCS Root - it can be turned on for one root and off for another at the
same time;
3. Build Configuration - like 2 but for build configurations;
4. or you can suggest something more suitable for you

Thanks for your reply Sergey,

We are only looking at introducing a continuous build system to our
processes now, it could very well be that old habits are clouding my
thinking. That said:

StarTeam has an integrated defect tracking system. If a label is
marked as "use as a build label" then the label is made available to
the StarTeam defect tracking system and anyone can log defects against
the build label. It is typically our quality control team that log
defects.

In the past, we've only created "build labels" when we release to our
quality control team.

My thinking was that our quality control team would become confused
with the many extra build labels that a continuous build system would
produce. I like the idea of labeling all builds, but am not crazy
about exposing all of them to our defect tracking system.

-Lee-

---
Original message URL:
http://www.jetbrains.net/devnet/message/5231973#5231973

--
Sergey Anchipolevsky
Software Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Thanks for following up!

#1 would be helpful
#2 would be more helpful
#3 is the best.

I don't know if this fits into your model, but I wonder if it might also be interesting to specify/override the label and label type based on build trigger type.

For example I might want my nightly builds to have build labels and my continuous builds to have non-build labels.

It would also be interesting to override the label name for different build trigger types.  For example, maybe I would want "ci-%system.build.number%" for continuous builds and "nightly-%system.build.number%" for scheduled builds.

I expect this could be achieved by creating duplicate configurations, but it would be a luxury not to have to duplicate a config to achieve this.

-Lee-

0
Comment actions Permalink

Hello Lee,

OK. This is pretty much worth a separate change request. :)
You can file one into our issue tracker - http://www.jetbrains.net/tracker

Option #3 also requires some effort which we cannot afford until 4.1 is issued.

As a quick temporary solution for TeamCity 4.1 I'm going to disable build
labels completely.
Is it an acceptable solution for you and would you like to receive a patch
with the fix before the official release?

Thanks for following up!

#1 would be helpful
#2 would be more helpful
#3 is the best.
I don't know if this fits into your model, but I wonder if it might
also be interesting to specify/override the label and label type based
on build trigger type.

For example I might want my nightly builds to have build labels and my
continuous builds to have non-build labels.

It would also be interesting to override the label name for different
build trigger types. For example, maybe I would want
"ci-%system.build.number%" for continuous builds and
"nightly-%system.build.number%" for scheduled builds.

I expect this could be achieved by creating duplicate configurations,
but it would be a luxury not to have to duplicate a config to achieve
this.

-Lee-

---
Original message URL:
http://www.jetbrains.net/devnet/message/5232008#5232008

--
Sergey Anchipolevsky
Software Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Thanks Sergey,

I am finding that your responsiveness to the issues I'm raising is stunningly good.  I thank you for that.

We've decided, for now, to go for a nightly build only - for this a build label is appropriate.

If we start to do continuous builds, we will, for now create a separate configuration that will not label.

So the TeamCity behaviour is not currently exactly what we'd like but we can live with it for now.

I recommend that you do not disable StarTeam build labels completely in TeamCity v4.1 as it will change the base behaviour for your StarTeam users - which would probably be more disruptive than helpful.

-Lee-

0
Comment actions Permalink

Hello Lee,

OK. Thank you for your suggestion.
I'll then keep it as is in 4.1 and rethink this behavior for later releases
according to your request.
Please don't hesitate to contact us for any problems with TeamCity.

Thanks Sergey,

I am finding that your responsiveness to the issues I'm raising is
stunningly good. I thank you for that.

We've decided, for now, to go for a nightly build only - for this a
build label is appropriate.

If we start to do continuous builds, we will, for now create a
separate configuration that will not label.

So the TeamCity behaviour is not currently exactly what we'd like but
we can live with it for now.

I recommend that you do not disable StarTeam build labels completely
in TeamCity v4.1 as it will change the base behaviour for your
StarTeam users - which would probably be more disruptive than helpful.

-Lee-

---
Original message URL:
http://www.jetbrains.net/devnet/message/5232082#5232082

--
Sergey Anchipolevsky
Software Developer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Lee,

BTW, you might find manual labeling usefull.

You can manually label only the builds you need to put build label to (the action is available form the Changes page of the build).

Do you really need non-build labels provided TeamCity displays build-changes/revision correspondence?

--
Best regards,

Yegor Yarko
Project Manager (TeamCity)
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0
Comment actions Permalink

Hmm... thanks, that is a very valid point!

If we want to go back and label a previously unlabled build, we can do so manually through TeamCity's change history tracking.

It means relying on and trusting TeamCity more, but that's fine, I think.

I think that's a very good solution to my issue.

-Lee-

0

Please sign in to leave a comment.