0
votes

I have set up my TeamCity 10.0.3 to create an assembly version number during the project build that uses the build.vcs.number (which corresponds to the changset number on the VCS Root - taken from Plastic SCM) as one of the parts.

The format is similar to this; {major}.{Minor}.{build.vcs.number}.{build counter}

This method has worked perfectly for quite some time returning the changset number (and only the number) from my VCS system.

The Plastic plugin for TeamCity has now been upgraded to the latest version (SNAPSHOT-201611231807) and since the upgrade after the VCS Root has been created the build will successfully return the changeset number that can be used within the assembly version number.

The error occurs as soon as anyone checks something into the monitored branch - at this point if an automatic or manual build is triggered the information returned as build.vcs.number has lots of additional information that breaks the build. An example of what is returned after a checkin is: cs.418 (guid:6a2d5c45-b1b8-4f03-889c-3f3c80c6e209) This appears to be both the changeset number along with the ID of the changset.

If I re-create the VCS root from scratch the correct number will be returned - until something is checked back in.

How can I resolve this error as all I want returned is the changset number

many thanks in advance

1

1 Answers

0
votes

We have just released a new Teamcity plugin version including new features and a big code refactor. We are aware of this problem and we are going to configure the "build.vcs.number" variable to always show the changeset number (as we do in previous versions of the plugin). The task should be done very soon.

Please contact us at support at codicesoftware dot com if you need more information.