Getting the changelist number that triggered the build

I've recently discovered that the {build.vcs.number.N} property returns the most recent changelist number (perforce) rather than the changelist number that triggered the build. Judging from some other posts that I've seen on this topic, I've discovered that a) JetBrains doesn't consider this tobe a serious problem and b) there's no easy workaround built into TeamCity.

My question is two-fold: 1) am I correct about those things I just mentioned? and 2) If so, what have people done in their build environments to work around this problem.

And to answer another question that was asked concerning this problem by a TeamCity moderator about why getting the latest changelist across the entire depot is not good enough:

We have a multi-branch environment where each branch is being built by a separate TeamCity configuration. Let's say there are three branches (BRANCH1, BRANCH2 and BRANCH3). If changes are made in BRANCH1 (changelist 1),BRANCH2(changelist 2) and BRANCH3(changelist 3) by separate developers within a 5 minute period and you only have one build agent then the BRANCH1 build will start and use changelist 1 as its {build.vcs.number.N}. That works. But while its building changelist(cl) 2 and 3 were checked into BRANCH2 and BRANCH3 respectively. Now they are both pending. When it's time for BRANCH2 to build, it uses "3" for {build.vcs.number} instead of 2. It finishes its build and BRANCH3 starts building and uses "3" again since that's still the most recent. Now there are two branch builds with the same build number.

Thanks for your help,
Karim

Edited by: Karim on Nov 13, 2008 4:51 AM

1 comment
Comment actions Permalink

There is an issue in our tracker: http://jetbrains.net/tracker/issue/TW-4527 Please watch/vote for it, feel free to add your comments too. Specifically we need to know use cases why do you want to use build.vcs.number in your build number and what problems you want to solve with it.

--
Pavel Sher

0

Please sign in to leave a comment.