Jump to content

Problems with TeamCity plugin


Recommended Posts

Thanks for the fast reply. Hopefully this improves the situation; we will see... At the moment the issue is not a big deal, because we just have a few build configurations in TeamCity, so that the issue occurs once or twice a week or so. But it would be a real pain if we move over all of our projects... what we are planning to do.

So let's wait for the bug fixed version... ;-)

Link to comment
Share on other sites

  • Replies 90
  • Created
  • Last Reply

Any news on this issue? I haven't managed to get it to build at all yet, so maybe it's not the same issue - but I do get the eternal 'checking for builds'. I tried setting up logging, but all I get in cm.log.txt is:

2012-01-17 13:09:16,140 INFO  2860 cm - STARTING CLIENT
2012-01-17 13:09:18,203 DEBUG 2860 ClientConfig - Time loading client.conf (C:\Program Files\PlasticSCM4\client\client.conf) 1969 ms
2012-01-17 13:09:18,406 INFO  2860 Shell - Setting encoding for standar input: Western European (Windows)

Link to comment
Share on other sites


Nightly builds: we run about 6 hours of automated tests (24 real hours but in parallel) but later we like to run exploratory. So publishing "nightly as-is" is quite hard to be a real option, isn't it?

Ok, how about a "weekly build"? It was just a thought; but I think having a regular "as-is" build (as opposed to official releases) might help you locate bugs and get them fixed a little faster. Seems like each "offical release" is an incremental fix to a bug, but it hasn't yet been a complete fix for the bug yet (at least in my case). If I had access to periodic builds, I could have identified the next stage of the fix and communicated that to you and maybe we would have had a complete bug fix faster. Rather than waiting 4 iterations of "official releases" before it's [hopefully] fixed.

Link to comment
Share on other sites

Another strange behavior that I just noticed. TeamCity in it's status seems to show the correct changeset, ie: cs:186@rep:ThreeSixty@repserver:dev-storage:8087, but when you do a cm status in the work directory (which my project does in order to generate version metadata) it comes up with an old changeset (in this case cs:180@rep:ThreeSixty@repserver:dev-storage:8087). I'm not sure if this is a TeamCity issue or a Plastic issue.

I had a similar issue with subversion once, but in that case it wasn't even building the proper code, but Plastic is building the proper code. Any ideas? :(

Link to comment
Share on other sites

Hi guys!

The new release is out! You can download the 239.2 release from our downloads page and review the release notes here:http://www.plasticsc...-402392-is-out/

As you can see the new release includes this bug fix:

TeamCity plugin: it was labelling always the changeset loaded in the

workspace, which could not be the changeset used in the build.

The plugin has been changed to label the appropriate changeset: the

one that has been tested in the build

and this one:

Java-related plugins: Added more log entries. The logger name is

"PlasticSCMJavaCore". Fixed a potential deadlock when syncing the java

core with cm.exe process.

This last one is the one that, hopefully, will help with the cm process issue.

Try it!

Link to comment
Share on other sites

So far so good, but I need to try a few cycles to be sure; it seemed like the first build always worked right.

Also, I'm still seeing: #1.1.cs:198@rep:ThreeSixty@repserver:dev-storage:8087.2-207 from the: %build.vcs.number.Plastic_ThreeSixty% var, is that still to be expected? Seems like you mentioned that was going to be changed.

Link to comment
Share on other sites

Still seems to be working, I've had it do 3 build so far all without a hitch (as far as the cm.exe dead locking).

I am still having some issues with the repository change set numbers. So the last build that ran was:


But my versioning script (it's some MSBuild code I wrote) gave me the following:

[CheckValidBuild] CheckValidVersion_Inline

[CheckValidVersion_Inline] Set new Build to:198

Which matches what a: cm status gives me. (Screenshot here: http://screencast.com/t/hzPAmK1hmm)

Link to comment
Share on other sites

Yep, here's from the build log:

[09:46:10]: Checking for changes

[09:46:13]: Clean build enabled: removing old files from C:\TeamCity\buildAgent\work\116b18455dca4058

[09:46:13]: Clearing temporary directory: C:\TeamCity\buildAgent\temp\buildTmp

[09:46:13]: Checkout directory: C:\TeamCity\buildAgent\work\116b18455dca4058

And if you look at the screenshot I posted, you'll see that's the folder that my command prompt is in.

Link to comment
Share on other sites

I'm having the same issue with the changeset number using parameter "%build.vcs.number% " in teamCity. It was working fine for a while, where my build number format was "0.1.%build.vcs.number%.{0}" .... now that parameter resolves to something like "0.1.cs:55@rep:MMG.GEN.Asthma.ERF@repserver:MMG-ITOP:8087.74". The stack trace indicates that it's in the parsing logic that is suppose to extract the revision number out "55". Any help would be greatly appreciated as I'm looking to start migrating all of our projects into PSCM+TeamCity.

***UPDATE: release 239.2 seems to have fixed this issue for now... I'll keep testing as I have had this fixed before and then suddenly stopped working again.

Link to comment
Share on other sites


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

  • Create New...