[JIRA] (JENKINS-59300) p4-plugin sets client root to null with template workspaces

16 views
Skip to first unread message

kwirth@perforce.com (JIRA)

unread,
Sep 10, 2019, 11:01:02 AM9/10/19
to jenkinsc...@googlegroups.com
Karl Wirth created an issue
 
Jenkins / Bug JENKINS-59300
p4-plugin sets client root to null with template workspaces
Issue Type: Bug Bug
Assignee: Unassigned
Components: p4-plugin
Created: 2019-09-10 15:00
Environment: P4 Plugin 1.10.3
Jenkins 1.276.1
Labels: P4_VERIFY
Priority: Minor Minor
Reporter: Karl Wirth

A poll will always set the workspace root to null when using template workspaces.

 

Reproduction steps:

(1) Create a freestyle job using a template workspace using the workspace naming convention 'jenkins-${JOB_NAME}'.

(2) Set it to not run concurrent executions and pin to a specific node. This is important because the workspace name is invalid if it need to run concurrently or on more than one node.

(3) Set it's build trigger to be polling.

(4) Build the job. A client is created with a valid root.

(5) Run 'Poll Now'. The workspace root is set to 'null'. For example:

Client:	jenkins-nullRoot
Update:	2019/09/10 14:00:40
Access:	2019/09/10 14:00:00
Owner:	admin
Root:	null
Options:	noallwrite noclobber nocompress unlocked nomodtime normdir
SubmitOptions:	submitunchanged
LineEnd:	local
View:
	//depot/00342303-nullRoot/... //jenkins-nullRoot/...

Suggested Workaround:

Include '${NODE_NAME}' in the workspace name and run on a slave that is not the master where polling occurs.

Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

kwirth@perforce.com (JIRA)

unread,
Sep 30, 2019, 7:39:02 AM9/30/19
to jenkinsc...@googlegroups.com

kwirth@perforce.com (JIRA)

unread,
Sep 30, 2019, 7:41:02 AM9/30/19
to jenkinsc...@googlegroups.com
Karl Wirth commented on Bug JENKINS-59300
 
Re: p4-plugin sets client root to null with template workspaces

Customer has highlighted following additional information:

 

I was just having a quick look at the p4-plugin source here:

 https://github.com/jenkinsci/p4-plugin/blob/81735fd4061943c8a122bfbc19e82b200094195d/src/main/java/org/jenkinsci/plugins/p4/PerforceScm.java

 and I noticed the following (on line 420) which sets the Root to “null” explicitly: 

  // JENKINS-48434 by setting rootPath to null will leave client's root unchanged
  ws.setRootPath(null);

 So this was clearly done on purpose to fix the following issue which wiped out the JENKINS_HOME area for another customer:

 https://issues.jenkins-ci.org/browse/JENKINS-48434

 I guess keeping a valid Root setting would be better than setting It to “null” and that was suggested on JENKINS-48434.

JENKINS-48434 appears to have broken an earlier fix for a similar issue: JENKINS-46908

howsdav@gmail.com (JIRA)

unread,
Jan 7, 2020, 5:56:02 PM1/7/20
to jenkinsc...@googlegroups.com

So, i've just been bitten hard by this in or Prod environment.

I'm not by any means fluent in Java, but it looks like the issue is proximally caused by the line you mentioned, but actually caused because the deepClone() is actually not a deep clone, but rather a shallow clone.

Consider the call to deepClone() here it simply calls [clone()|https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html] which per Javadoc is a shallow copy.

 

howsdav@gmail.com (JIRA)

unread,
Jan 7, 2020, 6:04:02 PM1/7/20
to jenkinsc...@googlegroups.com
David Hows edited a comment on Bug JENKINS-59300
So, i've just been bitten hard by this in or Prod environment.

I'm not by any means fluent in Java, but it looks like the issue is proximally caused by the line you mentioned, but actually caused because the deepClone() is actually not a deep clone, but rather a shallow clone. My understanding is that this would make all the subobjects references to the original and any changes would be reflected in both.

Consider the call to deepClone() [here|[https://github.com/jenkinsci/p4-plugin/blob/master/src/main/java/org/jenkinsci/plugins/p4/workspace/Workspace.java#L165]
] it simply calls [clone()| [ https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html]] which per Javadoc is a shallow copy.

 

howsdav@gmail.com (JIRA)

unread,
Jan 7, 2020, 6:04:04 PM1/7/20
to jenkinsc...@googlegroups.com

howsdav@gmail.com (JIRA)

unread,
Jan 7, 2020, 6:04:04 PM1/7/20
to jenkinsc...@googlegroups.com

howsdav@gmail.com (JIRA)

unread,
Jan 7, 2020, 7:02:03 PM1/7/20
to jenkinsc...@googlegroups.com
David Hows updated an issue
 
Change By: David Hows
Comment:
So, i've just been bitten hard by this in or Prod environment.

I'm not by any means fluent in Java, but it looks like the issue is proximally caused by the line you mentioned, but actually caused because the deepClone() is actually not a deep clone, but rather a shallow clone. My understanding is that this would make all the subobjects references to the original and any changes would be reflected in both.

Consider the call to deepClone() [here|[https://github.com/jenkinsci/p4-plugin/blob/master/src/main/java/org/jenkinsci/plugins/p4/workspace/Workspace.java#L165]] it simply calls [clone()|https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html] which per Javadoc is a shallow copy.

 
Reply all
Reply to author
Forward
0 new messages