Jump to content

Jenkins plugin removes workspace even with Use Update flag = true


Recommended Posts

Hi all,


I have the latest Jenkins and latest Plastic plugin for it. I am attempting to set up a Unity build machine.


Anyway, each time I build, the Plastic Jenkins plugin is removing the existing workspace and re-downloading it in its entirety. This is even with the "Use Update" flag set to true in the project configuration. This is not what I want as our build is capable of working incrementally and just switching to the head of /main each time we want a new build. The time difference is like 3m vs 40m. 


This seems like a bug. I know that it used to be a bug around v2 of the plugin, but was since fixed. 


Can someone help?

Link to comment
Share on other sites

Some other things of note:


- Jenkins is set to run as the currently logged in user.

- Jenkins is pointing to a custom workspace folder

- This is all on Windows 10

- My plastic installation is NOT the very latest. It is Smoke on The Water. (We're on a slightly old one because of a bug with later versions of Unity and the Plastic plugin causing huge lag)

Link to comment
Share on other sites

  • 1 month later...


My Jenkins and PlasticSCM are working complately fine.

Use Update is working OK as long as I am not changeing selector value (sometimes I need to tune branch).

Could you please tell me what is the reason to delete complately workspace in such case and re-create it from scrach?

Generally it would not be a big problem except that my repo is quite big and when workspace is deleted my cloaked, ignore and hidden_change configuration is also complately removed :(

Especially that in GUI I am switching between branches and even repositories and/or server and there is no need to re-create workspace.

Thanks in advance for the answer.

Link to comment
Share on other sites

  • 3 weeks later...
  • 2 months later...


I have noticed new Jenkins plugin version (2.5)with some corrections around "Use Update".

So checked again behaviour with parametrized selectors and workspace deletion...

It looks that the issue is still present :(

I went quickly through plugin code (at GitHub) and this is what I have found:

PlasticSCM.checkout(...) -> PlasticSCM.isWorkspaceDeleteNeeded -> workspaceConfiguration.equals(...) -> builder.append(this.selector, other.selector);

So it looks that in fact any change in selector will always lead to Workspace deletion and re-creation from the scrach...

Do you plan to change this behaviour? Or at least please do not delete conf files (cloaked, hidden_changes and ignore).

Link to comment
Share on other sites




you can give a try to the GitServer feature of the latest Plastic SCM server.... connect Jenkins to Plastic via Git and that should do the trick :) 



Link to comment
Share on other sites

I would like to :)

But my company is not able to upgrade server due to some issue - as far as I know administators already have contacted with Codice and you work on solution.

PS. GitServer has one restriction which is pretty problematic - lack of authentication and security.

I would propose (as first step) to add option to be able to configure Git access as ReadOnly.

Link to comment
Share on other sites

Hi Misieq,


please ask the admins to send a reminder, can't see pending issues from "compower".


Regarding GitServer configuration, what do you miss from the documentation, did you read this guide? https://www.plasticscm.com/documentation/gitserver/plastic-scm-version-control-gitserver-guide.shtml


And yes, right now the service is not having security or RO access, I really like the last one and should be easy to get done, you are kindly requested to add the idea here:  https://plasticscm.uservoice.com/forums/15467-general

Link to comment
Share on other sites


Compower is not my company address but private.

So I really doubt if my ISP even knows about Codice :)

But admins from my company are pinged by me from time to time so I am quite sure that they did not forget about upgrade.

Regarding guide I went through.

That is why I mentioned restriction which bothers me the most.

PS. Idea posted: https://plasticscm.uservoice.com/forums/15467-general/suggestions/13783221-configurable-read-only-access-for-gitserver

Link to comment
Share on other sites

  • 3 months later...



I am completely new around here ;) I don't know if my issue is the same as Misieq's (I don't know what the "selector" is) but I've also noticed that Jenkins plugin is deleting one of PlasticSCM workspaces even if there were no changes to the workspace. I've run one build after another and I've noticed this behaviour. Here is part of the Jenkins log:

[CommonLib] $ "c:\Program Files\PlasticSCM5\client\cm.exe" rmwk wk:CommonLib\
The workspace CommonLib\ has been deleted.
[CommonLib] $ "c:\Program Files\PlasticSCM5\client\cm.exe" mkwk CommonLib\ . --selector=selector849559857143387732.txt
Workspace CommonLib\ has been correctly created
[CommonLib] $ "c:\Program Files\PlasticSCM5\client\cm.exe" update .

My plugin version is 2.5 and of course I have "update" turned on.

Link to comment
Share on other sites

Hello Carlos


You mean that 2.6 shall fixed behaviour with deletion of workspace in case of parametrized selector?


It is not mentioned in Change Log.

Moreover I checked on GitHub and in classes I spotted there are no changes in this area.


Or maybe you was answering only for Wodzu's post.

If so could you please tell me when do you plan to work on "parametrized selector" issue (and Pipeline workflow approach mentioned here: http://www.plasticscm.net/index.php?/topic/3468-jenkins-plasticscm-compatibility-with-pipelines-workflows/). Thanks in advance for any info.

Link to comment
Share on other sites

Hi Misieq,


we changed the way the selector is parsed so we don't force unneeded updates operations. Not sure if it's your case but it's worth to try it out.





Can you give it a try and give us feedback? If it keeps failing we'll schedule internal test to give you a fix.

Link to comment
Share on other sites


I have checked it with newest version of plugin.

It still behaves in the same way.

As previously in build log following line appears:

Deleting workspace as the configuration has changed since the last build on this computer.

I am still thinking that "path" which I pointed in one of the previous posts is the main root cause of such behaviour.

Link to comment
Share on other sites

I'm sorry but I can't reproduce the issue.

Can you tell me if you osee the same behavior after creating a new Jenkinks project? This is what I get after creating a brand new one:

Started by an SCM change
Building in workspace C:\Program Files (x86)\Jenkins\workspace\TestingPlasticSCMPlugin
[ZZZ_Wks] $ cm lwk --format={0}#{1}#{2}
ZZZ_Wks#SUPERAWESOMECOM#c:\Program Files (x86)\Jenkins\workspace\TestingPlasticSCMPlugin\ZZZ_Wks
[ZZZ_Wks] $ cm ss wk:ZZZ_Wks
Selector for workspace ZZZ_Wks:
repository "ZZZ@localhost:8087"  path "/"    smartbranch "/Production"

[ZZZ_Wks] $ cm update "c:\Program Files (x86)\Jenkins\workspace\TestingPlasticSCMPlugin\ZZZ_Wks"
Downloading big file c:\Program Files (x86)\Jenkins\workspace\TestingPlasticSCMPlugin\ZZZ_Wks\trigger.txt (12 bytes)
Copied c:\Program Files (x86)\Jenkins\workspace\TestingPlasticSCMPlugin\ZZZ_Wks\trigger.txt
[ZZZ_Wks] $ cm wi "c:\Program Files (x86)\Jenkins\workspace\TestingPlasticSCMPlugin\ZZZ_Wks" --machinereadable --fieldseparator=def#_#sep
[ZZZ_Wks] $ cm find changeset where date between '2016-09-07T12:49:13' and '2016-09-07T12:57:08' and branch='/Production' on repositories 'ZZZ@localhost:8087' --xml --dateformat=yyyy'-'MM'-'dd'T'HH':'mm':'ss
<?xml version="1.0" encoding="utf-8" ?>
[ZZZ_Wks] $ cm gwp "c:\Program Files (x86)\Jenkins\workspace\TestingPlasticSCMPlugin\ZZZ_Wks" --format={1}
c:\Program Files (x86)\Jenkins\workspace\TestingPlasticSCMPlugin\ZZZ_Wks
[ZZZ_Wks] $ cm diff cs:313@ZZZ@localhost:8087 --format={path}#@_sep_@#{revid}#@_sep_@#{parentrevid} --repositorypaths
Finished: SUCCESS

It's a build triggered by a new change in the repository, only one file is downloaded and the workspace is preserved.

Link to comment
Share on other sites


I think you did not catch exactly my use case.

So my Jenkins Job has following configuration:
1) String Parameter named branch added with default value "/main"
2) Selector defined as:

repository "<repository>@<server>:8087"
path "/"
smartbranch "%branch%"

First build (with branch parameter set to /main) of this job (when no workspace is yet created) generates following output (behaviour correct):

Building in workspace c:\j\workspace\Tutorial
[tutorial] $ cm lwk --format={0}#{1}#{2}
[tutorial] $ cm mkwk tutorial c:\j\workspace\Tutorial\tutorial --selector=c:\j\workspace\Tutorial\tutorial\selector4578542194289647674.txt
Workspace tutorial has been correctly created
[tutorial] $ cm update c:\j\workspace\Tutorial\tutorial

Second build (again with branch parameter set to /main) - behaviour is correct (workspace is only updated not recreated):

Building in workspace c:\j\workspace\Tutorial
[tutorial] $ cm lwk --format={0}#{1}#{2}
[tutorial] $ cm ss wk:tutorial
Selector for workspace tutorial:
repository "tutorial@uskoaa37.northamerica.delphiauto.net:8087"	path "/"		smartbranch "/main"

[tutorial] $ cm update c:\j\workspace\Tutorial\tutorial

Third build (this time I have changed branch parameter value to /main/j_TUT-210) - workspace is recreated (behaviour is not correct).

Building in workspace c:\j\workspace\Tutorial
Deleting workspace as the configuration has changed since the last build on this computer.
[tutorial] $ cm lwk --format={0}#{1}#{2}
[tutorial] $ cm rmwk wk:tutorial
The workspace tutorial has been deleted.
[tutorial] $ cm mkwk tutorial c:\j\workspace\Tutorial\tutorial --selector=c:\j\workspace\Tutorial\tutorial\selector5342539367101548308.txt
Workspace tutorial has been correctly created
[tutorial] $ cm update c:\j\workspace\Tutorial\tutorial
Link to comment
Share on other sites

I'm sorry, I didn't pay enough attention to your post.


I'm afraid I can reproduce the issue using parametrized selectors, the system is not able to determine that the repository is still the same and just run an update operation.


I'll share this with the team and I'll give you an update asap.

Link to comment
Share on other sites

I think that formally system does not need to determine if repository and/or server is the same.


As far as I recall with GUI it is possible to just switch workspace to any repo on any server, isn't it?

So maybe it would be just enough to check (in case of "use update") that physical path and name of workspace is still the same as for previous build.

Link to comment
Share on other sites


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

  • Create New...