TeamCity & "patching"

[CodingGorilla]

As far as I can tell, the code that TeamCity builds is not part of the actual Plastic workspace, it's a "patch" generated by Plastic and copied to the build working directory. For me, this causes my version numbers to be incorrect, because I call 'cm status' and use the output to generate a VersionInfo.cs that contains the repository change set number used to make the build.

Is there a way to bypass this "patching" and have TeamCity build right out of the workspace? Or any other thought on how I can handle this?

[CodingGorilla]

I figured out, you can put a command line build step that does "cm update .\" and it updates the repository version information. Throws some warnings about not overwriting files but for me it keeps my versioning consistent.

[Olaf Kober]

Hi CodingGorilla!

You are right, the folder at your TeamCity agent isn't a real Plastic workspace, so running any cm command should be considered as "dangerous". But you can take another approach. TeamCity will provide your build script with an environment variable (or msbuild property) that contains VCS root information, including the Plastic changeset number.

For example, we use following code snippet in our msbuild scripts to obtain the changeset number:
 

<Target Name="GenerateRevisionNumber">
 
	<!-- output build-number supplied by teamcity -->
	<Message Text="build_vcs_number: $(build_vcs_number)"/>
  
	<!-- parse changeset from build-number supplied by teamcity or call cm status to obtain that information -->
	<PlasticWorkspaceStatus WorkspaceStatusResult="$(build_vcs_number)">
	  <Output TaskParameter="Changeset" PropertyName="ProductRevisionNumber"/>
	</PlasticWorkspaceStatus>
  
	<!-- default revision number to 0 -->
	<PropertyGroup Condition="'$(ProductRevisionNumber)'==''">
	  <ProductRevisionNumber>0</ProductRevisionNumber>
	</PropertyGroup>
  </Target>

 

The custom task PlasticWorkspaceStatus does some magic. It looks at the supplied property and either parses the changeset number out of if or runs the cm status command to obtain the current changeset number from the local workspace. When run under TeamCity the property is supplied; when run locally from command line, most of the time you will have a plastic workspace, it will call cm status.

You can find the source code and a pre-built assembly for the msbuild task at https://bitbucket.org/Amarok/tools/overview .

[CodingGorilla]

You are right, the folder at your TeamCity agent isn't a real Plastic workspace, so running any cm command should be considered as "dangerous". But you can take another approach. TeamCity will provide your build script with an environment variable (or msbuild property) that contains VCS root information, including the Plastic changeset number.

Yea.. I just found that out the hard way. I just pushed a build with some REALLY inconsistent code. I'll take a look at your suggestion, thanks Olaf!

[CodingGorilla]

TeamCity will provide your build script with an environment variable (or msbuild property) that contains VCS root information, including the Plastic changeset number.

Is this an automatic variable, or do I need to add this is a command line parameter to MSBuild (in the build task)?

[Olaf Kober]

Is this an automatic variable, or do I need to add this is a command line parameter to MSBuild (in the build task)?

It's a pre-defined TeamCity build parameter that is automatically provided to MSBuild. No need to configure anything.

Be aware of that this property is provided for your first VCS root. If you have multiple VCS roots attached to your build configuration, then I'm not sure what will happen...... read more about this here: http://confluence.je...uild+Parameters and http://confluence.je...d+Configuration (Last section: Using System Properties in Build Scripts).