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

  • Replies 90
  • Created
  • Last Reply
diegohb Rookie

diegohb

Posted
Posted

When i said it was working, I had just updated the plugin to the new version and I ran a build manually in teamcity which resulted in no new changes (rev55). Since then, I've created a new child branch, made a change, and merged back into the main branch. This checkin triggers TeamCity to get latest and build all, then set a label using build number. The build number with this latest change returned an invalid value again:

0.1.cs:57@rep:MMG.GEN.Asthma.ERF@repserver:MMG-ITOP:8087.91 (31 Jan 12 08:49) where the value shoudl have been "57".

Link to comment
Share on other sites
Corey.Caldwell Newbie

Corey.Caldwell

Posted
Posted

I may be experiencing a similar problem as Diego:

I've got a test repository that I've been playing with in preparation to move over to plastic. I added some code, got automated builds running, and then decided to delete all my changesets and reimport. Now that I've done that, my team city builds are broken. Its trying to generate the changeset list from cs:10 to cs:11 but there are no changesets anymore between 0 and 15 and the latest on that branch is 18.

I don't have a pressing need to get this squared up as I don't have a problem with deleting the repo and starting fresh. Still, it would really stink if someone deleted a changeset on our real repo, breaking the builds, and forcing us to start a fresh repo.

Link to comment
Share on other sites
  • 2 weeks later...
diegohb Rookie

diegohb

Posted
Posted

I was looking through the release notes but i couldn't find any reference to the bug I had mentioned parsing the revision number in the teamcity plugin. Has this been fixed with the latest release 4.0.239.9? is there a listing of releases for the teamcity plugin like there is for pscm ?

Link to comment
Share on other sites
  • 3 weeks later...
CodingGorilla Newbie

CodingGorilla

Posted
  • Author
Posted

I still have two issues with TeamCity, and I know they've been pointed out, but I just wanted to make sure these issues are still "Pending" and they weren't fixed while I wasn't looking. My TeamCity plugin currently shows: SNAPSHOT-201201241016 as the version.

1) The plugin versions still come out as the entire cm status line, like: 270@rep:ThreeSixty@repserver:dev-storage:8087. This actually seemed to go away, and then came back recently (here's a screenshot: http://screencast.com/t/kqjuKiigMa). That's what got me wondering, and made me post this.

2) During a TeamCity build, the version returned by TeamCity itself shows the proper changeset (as above), but running a 'cm status' from the command line in the TeamCity working directory returns really old changeset numbers. I've managed to work around this issue by adding an initial build step that does a 'cm update' before the actual build steps start running.

Link to comment
Share on other sites
  • 2 weeks later...
CodingGorilla Newbie

CodingGorilla

Posted
  • Author
Posted

Another issue to add to the TeamCity list: I'm not sure exactly where the issue comes from, but it seems like the TeamCity plugin does not read comments properly for the changesets.

For example, when I click on cs340 in the Branch Explorer, I see this:

http://screencast.com/t/xCflrzHU2nG

The comments read:

TSXTY-200
The bug tracker window no longer assigns anyone to the issue it creates

But in TeamCity I see:

http://screencast.com/t/SJ7xb1HIe

TSXTY-20 | 0The bug tracker window no longer assigns anyone to the issue it creates

For some reason it broke the "200" in half; there was a CR/LF after the 200, but no idea why it separated the last '0' and completely omitted the CR/LF.

Link to comment
Share on other sites
  • 1 month later...
  • 1 month later...
CodingGorilla Newbie

CodingGorilla

Posted
  • Author
Posted

I continue to have a lot of problems with teamcity, usually centered around the plugin giving an error like:


Caused by: jetbrains.buildServer.vcs.patches.UnsuccessfulPatchException: Failed to build patch for build #1.5.cs:553@rep:HappyV2@repserver:dev-storage:8087.2-68 {build id=335}, VCS root: repository "HappyV2@dev-storage:8087"
path "/"
smartbranch "/main/internal-beta" {instance id=15, parent id=10}, due to error: Error getting file contents: The specified revision was not found C:\teamcity-config\system\caches\plasticscm\plasticscm_-7218282057110341366\src\ThreeSixty.Client.Application\obj#cs:553@rep:HappyV2@repserver:dev-storage:8087;C:\TeamCity\temp\plasticscm2741997529040422784catresult\src\ThreeSixty.Client.Application\obj
[/Code]

Has there been (will there be) any work on the teamcity plugin? Seems like it hasn't been updated since late last year.

Link to comment
Share on other sites
manu Newbie

manu

Posted
Posted

Hello Coding Gorilla,

there's a task scheduled for the next sprint regarding the deleted changeset error and Team City. And in the incoming weeks we will have several engineers testing the whole system, included the Team City plugin so I think we'll improve a lot the quality of the plugin.

BTW, when TeamCity fails building the path what do you do to continue?

Link to comment
Share on other sites
Olaf Kober Newbie

Olaf Kober

Posted
Posted

Hi CodingGorilla, Manu!

I'm glad to hear that Codice will take some time to test/improve its TeamCity plugin. Since we use TeamCity a lot at my company and having the same troubles I would like to take the chance and add my two cents on this topic. I will summarize what we know about our problems in the hope that all them get fixed.

We are aware of two different bugs related to the error message mentioned by CodingGorilla.

BUG1:When you delete a changeset this will break TeamCity. This has also been reported yesterday by one of my colleague via e-mail. To repair TeamCity we usually re-create the VCS roots for this build configuration.

BUG2: There exists another problem when TeamCity picks up multiple changes (checkins), which contains the subsequent creation and deletion of a file. This has been reported by me some time ago via e-mail. Refer to DQ#SCM227886.

There exists another bug, but I never had the time to report until yet.

BUG3: The deletion of files and folders is not correctly propagated to the TeamCity Agent checkout folders (ex. d:\teamcity\work\f18aef796ec57e4d).

For example:

  • You have a branch with three files in it: A, B and C.
  • Now delete A.
  • TeamCity will periodical check for pending changes and update its cached folders (teamcity-config/system/caches/plasticscm). The file A will be deleted here.
  • Now a build configuration starts and TeamCity creates a patch with changes for the specific TeamCity Agent.
  • The patch is applied on the TeamCity Agent's checkout folder (that already contains an older workspace)
  • The patch will add new files, update existing ones, but does not delete file A.

Maybe this is a limitation of TeamCity's server-side checkout model. I don't know. We had some troubles with builds/tests that fail because of files deleted long ago that shouldn't be in the agent's checkout folder. To work around this we always use "force clean checkout", which unnecessarily increases the load on our infrastructure.

PERF-ISSUE4: This is not really a bug, more a performance/scalability issue. Nevertheless this is something that needs to be addressed.

At the moment we have about 40 TeamCity VCS roots of type Plastic SCM, all of them will be periodically checked by TeamCity for pending changes. As we move more projects from SVN to Plastic SCM about 50-70 additional VCS roots for Plastic SCM will be added.

Now, the problem is that only the 40 existing VCS roots generate such a high load (one core is used up to 100%) on our TeamCity server that I'm not sure how we should add even more projects. The high load exists even then when no TeamCity agent or build configuration is running. The periodically checking for pending changes generates the entire load.

This is what I was able to observe.

When TeamCity decides that is it about time to check for pending changes (you can configure this interval under Server Configuration / Global Settings / Default VCS changes check interval), the Plastic SCM plugin starts to spawn cm.exe processes one by one for each VCS root. This cm.exe performs some operations (I guess it undos changes, updates the workspace, etc.) on a single workspace and terminates. Directly afterwards the next cm.exe is started for the next VCS root / workspace.

To check for changes and update the workspaces all 40 cm.exe took about 2-4 minutes to complete. In this time frame the cm.exe processes utilize a single CPU core for about 100% of the time. The cpu load wouldn't be a problem, but it takes about 2-4 minutes for TeamCity to recognize that there are pending changes. Now add another 50 VCS roots/workspaces and then we will be at about 5-8 minutes. Our developers like to have fast feedback about their builds/tests after check-in, but it takes TeamCity (in worst case) 8 minutes to only recognize the checkin, not to mention the time it takes to start and run build configurations?!

That is not acceptable. Subversion for example is capable to check about 100 different VCS roots in a fraction of time.

My feeling is that the Plastic SCM plugin should distinguish between two different operations here. First, detecting pending changes. It should be able to do this in very short time, without updating an entire workspace (checking thousands of files and folders). Second, updating a workspace. This should be only done when a build configuration is started and an up-to-date workspace for patch creation is needed.

Uhh, a long post for a lot of troubles related to TeamCity.

Please Codice take some time and test/improve your TeamCity plugin. And do some load testing!!

Thanks,

Olaf

Link to comment
Share on other sites
manu Newbie

manu

Posted
Posted

Olaf, thank you so much for your report. The first issue is scheduled for the next sprint and the 2 others we will have to take a look into it.

There's a lot to improve in this plugin!

Thanks again for your time reporting.

Link to comment
Share on other sites
  • 1 month later...
CodingGorilla Newbie

CodingGorilla

Posted
  • Author
Posted

Any progress on this, Olaf's BUG2 bit me again tonight and I'm up all night trying to fix it. I looked for a new version of the plugin, but it looks like it hasn't changed (at least based on:

<version>SNAPSHOT-201201241016</version>

Maybe you've updated it and just not changed the version attribute?

Link to comment
Share on other sites
  • 3 weeks later...
  • 4 weeks later...
diegohb Rookie

diegohb

Posted
Posted

Not sure to create a new thread or continue on this one "Problems with Team City plugin"...

I've read that with other SCC plugins for teamcity you can configure it so that you only have ONE shared VCS root and then use parameters in the selector so that it can be used across all projects.. My selector is like this 

repository "%mmg.project.name%@SERVER.DOMAIN.COM:8087"
 path "/"
   branch "/%mmg.project.branch%"
   checkout "/%mmg.project.branch%"

but when i try to use it with more than one project, i have no luck... so for now, I configure a new vcs root for each project. is this a known bug/limitation of the Plastic plugin?

Link to comment
Share on other sites

Archived

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

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