Jump to content
Plastic SCM forums are now in Unity. Click here to open the new forum ×

Problems with TeamCity plugin

CodingGorilla

By CodingGorilla
in Integrations

Recommended Posts

Olaf Kober Newbie

Olaf Kober

Posted
Posted

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... ;-)

  • Replies 90
  • Created
  • Last Reply
Benjol Newbie

Benjol

Posted
Posted

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)

manu Newbie

manu

Posted
Posted

Hi Benjol!

I'm almost sure that is the same error :)

The next release will have the fix and it will be ready this week.

Sorry for the inconveniences...

Manu

psantosl Newbie

psantosl

Posted
Posted

Guys,

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?

CodingGorilla Newbie

CodingGorilla

Posted
  • Author
Posted

Guys,

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.

CodingGorilla Newbie

CodingGorilla

Posted
  • Author
Posted

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? :(

manu Newbie

manu

Posted
Posted

Hi CodingGorilla,

ummm, that's very strange since the TeamCity is also issuing a "cm status" from the working workspace....

Can we arrange a meeting to look into this issue?

Manu.

manu Newbie

manu

Posted
Posted

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!

CodingGorilla Newbie

CodingGorilla

Posted
  • Author
Posted

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:

199@rep:ThreeSixty@repserver:dev-storage:8087

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)

CodingGorilla Newbie

CodingGorilla

Posted
  • Author
Posted

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.

diegohb Rookie

diegohb

Posted
Posted

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.

Archived

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

Go to topic listing
×
×
  • Create New...