[JIRA] (JENKINS-40055) p4-plugin exception when used with the shared pipeline libraries plugin. p4.tasks.AbstractTask.setEnvironment

8 views
Skip to first unread message

darren.bowen@thirdkindgames.com (JIRA)

unread,
Nov 27, 2016, 4:13:02 AM11/27/16
to jenkinsc...@googlegroups.com
Darren Bowen created an issue
 
Jenkins / Bug JENKINS-40055
p4-plugin exception when used with the shared pipeline libraries plugin. p4.tasks.AbstractTask.setEnvironment
Issue Type: Bug Bug
Assignee: Paul Allen
Components: p4-plugin, workflow-cps-global-lib-plugin
Created: 2016/Nov/27 9:12 AM
Environment: workflow-cps-global-lib version 2.5
p4-plugin 1.4.10
Priority: Critical Critical
Reporter: Darren Bowen

I get a crash in the p4-plugin when I use it with the "Pipeline Shared Groovy Libraries Plugin". This plugin creates a Perforce workspace and syncs groovy code from Perforce which can be used in any Pipeline.

When the pipeline initialises it attempts to sync the shared code and crashes the pipeline with the TTY and callstack below. The crash is not present in version 2.4 of workflow-cps-global-lib, it started to happen in version 2.5 only.

I believe the issue is caused because the plugin tries to generate a local workspace root which contains an '@' symbol. My SCM configuration for the Global Pipeline Libraries is as follows, the shared libraries plugin requires a specific folder structure in the Jenkins workspace and attempts to mange the workspaces under the hood.

  • Manual (custom view)
  • View:
    //IT/Production/Scripts/Jobs/Shared/... //jenkins_shared_pipeline_code/...
  • Workspace name:
    jenkins_shared_pipeline_code
Started by user Root
Loading library shared@
java.lang.ArrayIndexOutOfBoundsException: 1
	at org.jenkinsci.plugins.p4.tasks.AbstractTask.setEnvironment(AbstractTask.java:106)
	at org.jenkinsci.plugins.p4.PerforceScm.checkout(PerforceScm.java:362)
	at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109)
	at org.jenkinsci.plugins.workflow.libs.SCMSourceRetriever.doRetrieve(SCMSourceRetriever.java:107)
	at org.jenkinsci.plugins.workflow.libs.SCMRetriever.retrieve(SCMRetriever.java:63)
	at org.jenkinsci.plugins.workflow.libs.LibraryAdder.retrieve(LibraryAdder.java:150)
	at org.jenkinsci.plugins.workflow.libs.LibraryAdder.add(LibraryAdder.java:131)
	at org.jenkinsci.plugins.workflow.libs.LibraryDecorator$1.call(LibraryDecorator.java:99)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1053)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:591)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:569)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:546)
	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
	at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
	at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
	at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:67)
	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:429)
	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:392)
	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:221)
	at hudson.model.ResourceController.execute(ResourceController.java:98)
	at hudson.model.Executor.run(Executor.java:404)
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
WorkflowScript: Loading libraries failed

1 error

	at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1073)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:591)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:569)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:546)
	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
	at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
	at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
	at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:67)
	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:429)
	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:392)
	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:221)
	at hudson.model.ResourceController.execute(ResourceController.java:98)
	at hudson.model.Executor.run(Executor.java:404)
Finished: FAILURE
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

jenkins@richardlee.name (JIRA)

unread,
Dec 29, 2016, 6:01:01 PM12/29/16
to jenkinsc...@googlegroups.com
Richard Lee commented on Bug JENKINS-40055
 
Re: p4-plugin exception when used with the shared pipeline libraries plugin. p4.tasks.AbstractTask.setEnvironment

Seeing this as well. This used to work, but appears to have broken recently. Looking at the source code, it appears the p4-plugin is making some assumptions about how jenkins workspace paths are formatted that may not, in fact, be valid.

jenkins@richardlee.name (JIRA)

unread,
Dec 29, 2016, 7:23:02 PM12/29/16
to jenkinsc...@googlegroups.com

jenkins@richardlee.name (JIRA)

unread,
Jan 3, 2017, 7:48:02 PM1/3/17
to jenkinsc...@googlegroups.com

pallen@perforce.com (JIRA)

unread,
Jan 4, 2017, 11:06:01 AM1/4/17
to jenkinsc...@googlegroups.com

Hi Guys, just getting back up to speed after the Christmas break.

The parsing of '@' is a bit fragile, I am aware of '@n' being added for build executors and '@script' added for pipeline scripts, however they may be other uses.

Please can you show me the workspace directories Jenkins has created for the Job (presumably they will contain '@' symbols and might give a clue to their use).

russell.gallop@gmail.com (JIRA)

unread,
Jan 4, 2017, 11:37:01 AM1/4/17
to jenkinsc...@googlegroups.com

> The parsing of '@' is a bit fragile, I am aware of '@n' being added for build executors and '@script' added for pipeline scripts, however they may be other uses.

I've also seen '@tmp' though I don't know how this is used (and whether it matters for the p4 plugin).

russell.gallop@gmail.com (JIRA)

unread,
Jan 4, 2017, 11:37:02 AM1/4/17
to jenkinsc...@googlegroups.com
Russell Gallop edited a comment on Bug JENKINS-40055
> The parsing of '@' is a bit fragile, I am aware of '@n' being added for build executors and '@script' added for pipeline scripts, however they may be other uses.

I've also seen '@tmp' though I don't know how this is used ( and or whether it matters for the p4 plugin).

jenkins@richardlee.name (JIRA)

unread,
Jan 4, 2017, 6:16:01 PM1/4/17
to jenkinsc...@googlegroups.com

If you use global libs, it appears to add @libs

$ ls workspace/
alpine-java@libs deploy-image-to-datacenter@libs deploy-whole-datacenter@libs dynconfig@libs FullRsyncBackup token@script
alpine-java@script deploy-image-to-datacenter@script deploy-whole-datacenter@script dynconfig@script token@libs

jenkins@richardlee.name (JIRA)

unread,
Jan 4, 2017, 6:21:01 PM1/4/17
to jenkinsc...@googlegroups.com
Richard Lee edited a comment on Bug JENKINS-40055
If you use global libs, it appears to add @libs files on the 'master'.

{{
$ ls workspace/
alpine-java@libs    deploy-image-to-datacenter@libs    deploy-whole-datacenter@libs    dynconfig@libs  FullRsyncBackup  token@script
alpine-java@script  deploy-image-to-datacenter@script  deploy-whole-datacenter@script  dynconfig@script  token@libs

}}

on the slave, it adds @n and @tmp

{{
$ ls -d workspace/dynconfig* workspace/token*
workspace/dynconfig  workspace/dynconfig@2  workspace/dynconfig@tmp  workspace/token  workspace/token@2  workspace/token@2@tmp  workspace/token@3  workspace/token@tmp
}}

jenkins@richardlee.name (JIRA)

unread,
Jan 4, 2017, 6:22:02 PM1/4/17
to jenkinsc...@googlegroups.com
Richard Lee edited a comment on Bug JENKINS-40055
If you use global libs, it appears to add @libs and @script files on the 'master'.

{quote}

$ ls workspace/
alpine-java@libs    deploy-image-to-datacenter@libs    deploy-whole-datacenter@libs    dynconfig@libs  FullRsyncBackup  token@script
alpine-java@script  deploy-image-to-datacenter@script  deploy-whole-datacenter@script  dynconfig@script  token@libs
{quote}


on the slave, it adds @n and @tmp

{quote}

$ ls -d workspace/dynconfig* workspace/token*
workspace/dynconfig  workspace/dynconfig@2  workspace/dynconfig@tmp  workspace/token  workspace/token@2  workspace/token@2@tmp  workspace/token@3  workspace/token@tmp
{quote}

jenkins@richardlee.name (JIRA)

unread,
Jan 4, 2017, 6:22:04 PM1/4/17
to jenkinsc...@googlegroups.com
Richard Lee edited a comment on Bug JENKINS-40055
If you use global libs, it appears to add @libs files on the 'master'.

{
{ quote}
$ ls workspace/
alpine-java@libs    deploy-image-to-datacenter@libs    deploy-whole-datacenter@libs    dynconfig@libs  FullRsyncBackup  token@script
alpine-java@script  deploy-image-to-datacenter@script  deploy-whole-datacenter@script  dynconfig@script  token@libs
{quote } }

on the slave, it adds @n and @tmp

{
{ quote}
$ ls -d workspace/dynconfig* workspace/token*
workspace/dynconfig  workspace/dynconfig@2  workspace/dynconfig@tmp  workspace/token  workspace/token@2  workspace/token@2@tmp  workspace/token@3  workspace/token@tmp
{quote } }

jenkins@richardlee.name (JIRA)

unread,
Jan 4, 2017, 8:18:03 PM1/4/17
to jenkinsc...@googlegroups.com

fwiw, I added some logging to AbstractTask.setEnvironment to print out the 'root' variable (buildWorkspace.getRoot()), which is checked for the existence of a '@' character, and then the 'name' (buildWorkspace.getName)) variable, on which an attempted split on '@' is done, which fails, resulting in the array index error when attempting to get the second part.

In this instance, 'dynconfig' is the pipeline job, and 'tivoPipeline' is the global library name.

Loading library tivoPipeline@now
setEnv root = /home/jenkins/workspace/dynconfig@libs/tivoPipeline
setEnv name = tivoPipeline
java.lang.ArrayIndexOutOfBoundsException: 1
at org.jenkinsci.plugins.p4.tasks.AbstractTask.setEnvironment(AbstractTask.java:110)

As you can see, the root has a '@' in a parent directory for the pipeline job, but the last component of the directory does not have a '@', as it is just the library name.

scm_issue_link@java.net (JIRA)

unread,
Jan 5, 2017, 10:14:01 AM1/5/17
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Paul Allen
Path:
src/main/java/org/jenkinsci/plugins/p4/tasks/AbstractTask.java
http://jenkins-ci.org/commit/p4-plugin/c6a01fe1d0023c78188f8d1d29edf8eb1dc1ce4e
Log:
Prevent NPE on paths with @ in the parent.

JENKINS-40055

pallen@perforce.com (JIRA)

unread,
Jan 5, 2017, 10:35:01 AM1/5/17
to jenkinsc...@googlegroups.com

jenkins@richardlee.name (JIRA)

unread,
Jan 5, 2017, 2:15:01 PM1/5/17
to jenkinsc...@googlegroups.com

pallen@perforce.com (JIRA)

unread,
Jan 6, 2017, 5:07:02 AM1/6/17
to jenkinsc...@googlegroups.com

I'll aim for next week; just need to check if any other features/fixes need to go out.

jglick@cloudbees.com (JIRA)

unread,
Feb 10, 2017, 3:59:01 PM2/10/17
to jenkinsc...@googlegroups.com

pallen@perforce.com (JIRA)

unread,
Mar 13, 2017, 7:40:04 AM3/13/17
to jenkinsc...@googlegroups.com
Paul Allen closed an issue as Fixed
 

Fixed in 1.4.13

Change By: Paul Allen
Status: Open Closed
Resolution: Fixed
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages