marioo Posted July 28, 2014 Report Share Posted July 28, 2014 We use PlasticSCM integration with Jenkins. I noticed that when I run PlasticSCM client on Jenkins's computer to display the list of existing workspaces, the list is incomplete for some reason. Many workspaces that actually exist on the disk are not included there. This has an influence on Jenkins. Let me explain you why. When a Jenkins job is run, the PlasticSCM plugin runs the following commands at the beginning: cm.exe lwk --format={0}#{1}#{2} cm.exe rmwk wk:WorkspaceName cm.exe mkwk WorkspaceName cm.exe update . The second command is executed only if PlasticSCM workspace associated with the job already exists. Because the first command returns an incomplete list of existing workspaces (just like PlasticSCM GUI does), the second command may not be executed when necessary. This later causes the workspace not to be fully updated. See a fragment of a console log from Jenkins being a result of calling the "cm update ." command: The file c:\Path\SomeFile.ext has been changed in the workspace. Won't overwrite. Because until today our Jenkins's configuration allowed concurrent builds, I have an impression that the cm command is not prepared for concurrency. At least as far as the above mentioned commands are concerned (those that modify the list of workspaces). I guess that PlasticSCM client has a single list of workspaces on a machine, right? So when several threads modify it at once with the cm command, its content becomes inconsistent. Is that possible? Could you please tell me how to solve the problem? Will it be enough to let Jenkins run only one job at a time? Thanks in advance. Link to comment Share on other sites More sharing options...
marioo Posted August 18, 2014 Author Report Share Posted August 18, 2014 There is the following release note for the 5.0.44.596 PlasticSCM version. Does it refer to the issue above? I mean does this version support concurrent Jenkins jobs now? Bug Jenkins plugin: The jenkins plugin did not reusePlastic SCM workspaces correctly when the'Use update' preference was set. Fixed. Link to comment Share on other sites More sharing options...
marioo Posted August 20, 2014 Author Report Share Posted August 20, 2014 I think I've answered my question. Seems that this post refers to the bug fix: http://www.plasticscm.net/index.php?/topic/2302-jenkins-hudson-plugin-sync-update-speed/ Link to comment Share on other sites More sharing options...
manu Posted August 20, 2014 Report Share Posted August 20, 2014 Hi Marioo, can you confirm that it's working now? Link to comment Share on other sites More sharing options...
marioo Posted August 21, 2014 Author Report Share Posted August 21, 2014 Hi Manu, We have already reconfigured Jenkins in such a way, that only one task can be run at a time, and the issue I mentioned in my first post does no longer occur. If you want, we'll remove that constraint and let you know in a few days if that issue still takes place or not. But before we do that, could you tell me what exactly the 5.0.44.596 version fixes? I mean, does it fix the concurrency issue I described or the lengthy workspace update issue I gave you a link to yesterday? Link to comment Share on other sites More sharing options...
calbzam Posted August 25, 2014 Report Share Posted August 25, 2014 Hi, The release fixes an issue with the "Use Update" option. The incremental builds were not properly working. Now you are able to use this option to avoid running always complete build. Regards, Carlos Link to comment Share on other sites More sharing options...
marioo Posted September 10, 2014 Author Report Share Posted September 10, 2014 Seems that the issue I described in my first post has not been solved by blocking concurrent Jenkins builds (PlasticSCM 5.0.44.596). For some reason the problem returned after a few weeks, I don't know yet why. We decided to switch off the use update option. PlasticSCM loses its workspace list when that option is active. Our nightly builds on Jenkins update xlinks before starting a build and unit tests of a project. Because an xlink update has to be followed by a checkin, and the workspace remains unclean when the use update option is checked, files that were modified during a previous build are checked in as well, which we don't want to take place. But that happens when PlasticSCM loses its workspace list information. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.