Olaf Kober Posted January 12, 2012 Report Share Posted January 12, 2012 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 More sharing options...
manu Posted January 12, 2012 Report Share Posted January 12, 2012 I'm negotiating to have it tomorrow Link to comment Share on other sites More sharing options...
CodingGorilla Posted January 12, 2012 Author Report Share Posted January 12, 2012 Manu, have you all considered nightly builds, that are released "as-is"? Link to comment Share on other sites More sharing options...
manu Posted January 12, 2012 Report Share Posted January 12, 2012 Manu, have you all considered nightly builds, that are released "as-is"? Yes yes, I'm dreaming about having nightly-builds. Link to comment Share on other sites More sharing options...
Benjol Posted January 18, 2012 Report Share Posted January 18, 2012 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 More sharing options...
manu Posted January 18, 2012 Report Share Posted January 18, 2012 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 Link to comment Share on other sites More sharing options...
psantosl Posted January 18, 2012 Report Share Posted January 18, 2012 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? Link to comment Share on other sites More sharing options...
CodingGorilla Posted January 18, 2012 Author Report Share Posted January 18, 2012 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. Link to comment Share on other sites More sharing options...
CodingGorilla Posted January 18, 2012 Author Report Share Posted January 18, 2012 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 More sharing options...
manu Posted January 19, 2012 Report Share Posted January 19, 2012 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. Link to comment Share on other sites More sharing options...
CodingGorilla Posted January 19, 2012 Author Report Share Posted January 19, 2012 Can we arrange a meeting to look into this issue? Sure, I'm in the Eastern Time Zone (UTC-5), it's 9am here right now and I'll be here until 5pm (save an hour for lunch). Link to comment Share on other sites More sharing options...
manu Posted January 19, 2012 Report Share Posted January 19, 2012 Thanks! I will try to find time to schedule the meeting. Manu. Link to comment Share on other sites More sharing options...
manu Posted January 25, 2012 Report Share Posted January 25, 2012 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 theworkspace, 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 More sharing options...
Olaf Kober Posted January 25, 2012 Report Share Posted January 25, 2012 Sweet!!! Downloading.... :-) Link to comment Share on other sites More sharing options...
CodingGorilla Posted January 25, 2012 Author Report Share Posted January 25, 2012 No update to the TeamCity plugin needed? Just the client? Link to comment Share on other sites More sharing options...
manu Posted January 25, 2012 Report Share Posted January 25, 2012 Update also the plugin the fix is inside it Link to comment Share on other sites More sharing options...
CodingGorilla Posted January 25, 2012 Author Report Share Posted January 25, 2012 Oh, I see the plugin on the download page, I didn't look hard enough the first time. It's still early, I'm not completely awake! Link to comment Share on other sites More sharing options...
manu Posted January 25, 2012 Report Share Posted January 25, 2012 No problem! I'm expectant to see it it works for you!!! Link to comment Share on other sites More sharing options...
CodingGorilla Posted January 25, 2012 Author Report Share Posted January 25, 2012 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 More sharing options...
manu Posted January 25, 2012 Report Share Posted January 25, 2012 Ok, keep testing it. Regarding the %build.vcs.number% variable, the task is scheduled for this sprint but, not started yet. Link to comment Share on other sites More sharing options...
CodingGorilla Posted January 25, 2012 Author Report Share Posted January 25, 2012 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) Link to comment Share on other sites More sharing options...
manu Posted January 25, 2012 Report Share Posted January 25, 2012 So far good news! Regarding the cset number, are you sure the TeamCity agent is using the same workspace as your program? Link to comment Share on other sites More sharing options...
CodingGorilla Posted January 25, 2012 Author Report Share Posted January 25, 2012 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 More sharing options...
manu Posted January 25, 2012 Report Share Posted January 25, 2012 Wow, that's strange! Can I connect with you to see if I can see the problem? Meeting link -> https://www2.gotomeeting.com/join/271193138 Link to comment Share on other sites More sharing options...
diegohb Posted January 31, 2012 Report Share Posted January 31, 2012 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 More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.