Jenkins: concurrent cm.exe calls lead to losing workspaces?

[marioo]

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:

1. cm.exe lwk --format={0}#{1}#{2}
2. cm.exe rmwk wk:WorkspaceName
3. cm.exe mkwk WorkspaceName
4. 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.

[marioo]

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 reuse
Plastic SCM workspaces correctly when the
'Use update' preference was set. Fixed.

[marioo]

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/

[manu]

Hi Marioo, can you confirm that it's working now?

[marioo]

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?

[calbzam]

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

[marioo]

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.