Jump to content

TeamCity plugin: incorrect workspace status (changeset number) at build agent


Olaf Kober

Recommended Posts

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: 3.0.187.22

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

The TeamCity build directory is not a Plastic workspace. TeamCity copies files from its internal workspace (the one you can see from a 'cm lwk') to a directory accessible to the build agent.

The reason the "cm status" command appears to work, and not complain about not being in a workspace, is because the .plastic/ directory has been copied too. That is a bug, and I should fix that. But it won't make "cm status" work in the build directory.

- Dick

Link to comment
Share on other sites

Hi Dick!

Thanks for your fast response. Now, I understand. I was heading down the wrong road,

thinking too much in SVN/HG terms, where a .svn/.hg folder means that you can perform

local operations. Of course, in PlasticSCM the client on the build machine would need

to know about the local workspace and that's not possible to achieve with TeamCity's

server-side checkouts.

Unfortunately, that has some consequences:

A) We are not able to run "cm status" to obtain workspace information. We would like to

do this to obtain the changeset number that is part of our product version. TeamCity

provides an alternative by supplying VCS information via a system property ("%system.build.vcs.number.<VCS NAME>%")

to build scripts. That seems to work...

B) We are not able to create and apply a label to the local workspace. Yes, I know

TeamCity is providing automatic labeling, but that's not flexible enough. We usually

decide from within the build script whether to label or not and also generate the

product version and thus the label name from within the build script.

For the future you should might considering to support TeamCity's agent-side VCS checkout

mode. All big players (svn, hg, git, tfs, perforce) support that checkout mode in TeamCity.

The advantage is that you have a full workspace on build agent-side and you can do what you

want in your build script.

Thanks, for your time.

Olaf

Link to comment
Share on other sites

Hi Olaf,

Great having feedbacks from you, it helps improves our plugins in this case TeamCity.

I inserted it as Customer Request in our internal tracking system and will be implemented in future releases, which one I cannot say for the moment.

cheers,

Miller

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...