Olaf Kober Posted April 8, 2011 Report Share Posted April 8, 2011 Hi! While trying to get our build automation to work, I noticed that workspace status, primarily changeset number, is not correct on build agent-side. What I mean is that the PlasticSCM Workspace that resides on the build machine (where the TeamCity Build Agent runs) returns an out-of-date changeset number when executing "cm status", even though files and folders where updated correctly. Here are steps to reproduce this: 1) Create a new Build Configuration in TeamCity with a new VCS Root of type Plastic SCM. 2) Run that Build Configuration. 3) Look at the TeamCity Build Log of the completed build to find out the exact folder path where the workspace copy resides that is used by the TeamCity Build Agent. 4) Navigate to that folder, open command prompt and run "cm status". It will return the expected changeset number. 5) Now, make a change to the branch the VCS Root is referring to. This checkin will increment the changeset number. 6) Run the Build Configuration once again. 7) Look at the TeamCity Build Log of the second build to ensure that the same folder path was used for the Build Agent Workspace. 8) Run "cm status" again. This time, it returns the exact same changeset number as before. Unfortunately that's wrong! We need this information to be correct, because the changeset number is part of our product version that is generated by the executing build script on the Build Agent. We are using: Plastic SCM: 22.214.171.124 TeamCity Plugin: SNAPSHOT-201103251611 TeamCity: 6.0.3 At the moment, I was not able to find a workaround. Even enforcing TeamCity to cleanly checkout does not solve the problem. Olaf Link to comment Share on other sites More sharing options...
This topic is now archived and is closed to further replies.