[JIRA] [workflow-plugin] (JENKINS-26481) Mishandling of binary methods accepting Closure

112 views
Skip to first unread message

be_ray@sbcglobal.net (JIRA)

unread,
Jul 16, 2015, 3:02:02 PM7/16/15
to jenkinsc...@googlegroups.com
Brian Ray commented on Bug JENKINS-26481
 
Re: Mishandling of binary methods accepting Closure

Might be a silly question but does this issue cover Collection#inject as well? I'm seeing truncated behavior consistent with the above in 1.8, and assume that it calls each under the covers as with the other iterating closure-accepting methods above.

Thanks
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
Atlassian logo

rawlingsj80@gmail.com (JIRA)

unread,
Sep 20, 2015, 4:45:02 PM9/20/15
to jenkinsc...@googlegroups.com

I think I've just hit this same problem, using the workflow plugin I'm reading a multiline file but unable to loop over each line, I only get one line printed in this example..

def file = readFile('MultiLineFile.txt')
file.eachLine { line ->
  println line
}

jglick@cloudbees.com (JIRA)

unread,
Sep 21, 2015, 5:02:02 PM9/21/15
to jenkinsc...@googlegroups.com

That is the same. You need to split and use a C-style loop.

rawlingsj80@gmail.com (JIRA)

unread,
Sep 21, 2015, 5:21:01 PM9/21/15
to jenkinsc...@googlegroups.com

Yeah figured it was worth mentioning and thanks for the original comments as it helped me move on. For completeness and to complement above answer here's what I used..

def lines = new String(multiLineFile).split( '\n' )
for(int i = 0; i < lines.size(); i++){
  println lines[i]
}

jglick@cloudbees.com (JIRA)

unread,
Sep 21, 2015, 5:32:02 PM9/21/15
to jenkinsc...@googlegroups.com

That works, though note that new String(multiLineFile) is redundant; you can just use multiLineFile directly.

rawlingsj80@gmail.com (JIRA)

unread,
Sep 21, 2015, 5:36:01 PM9/21/15
to jenkinsc...@googlegroups.com

Awesome - thanks!

frederic.chuong@gmail.com (JIRA)

unread,
Sep 23, 2015, 1:15:03 PM9/23/15
to jenkinsc...@googlegroups.com

workflow-plugin 1.10, using @com.cloudbees.groovy.cps.NonCPS does produce the expected output (when combined with synchronous steps such as org.jenkinsci.plugins.workflow.steps.EchoStep.Execution) as a workaround to groovy-cps #9.

@com.cloudbees.groovy.cps.NonCPS
def foo1() {
  [1, 2, 3].each {
    println it
  }
}

@com.cloudbees.groovy.cps.NonCPS
def foo2() {
  println "abc".replaceAll(/[a-z]/) {
    it.toUpperCase()
  }
}

node {
  foo1()
  foo2()
}

Started by user anonymous
Running: Allocate node : Start
Running on master in xxx
Running: Allocate node : Body : Start
Running: Print Message
1
Running: Print Message
2
Running: Print Message
3
Running: Print Message
ABC
Running: Allocate node : Body : End
Running: Allocate node : End
Running: End of Workflow
Finished: SUCCESS

jglick@cloudbees.com (JIRA)

unread,
Sep 23, 2015, 3:33:04 PM9/23/15
to jenkinsc...@googlegroups.com

Frédéric Chuong while it may work to run certain steps inside a @NonCPS method (generally only those using AbstractSynchronousStepExecution: echo, error, pwd), in general it will fail horribly, so my recommendation is to never call any step from inside such a method: just use it to do some computation and then pass the result back to the flow. Ideally the engine would automatically detect the attempt and reject it.

frederic.chuong@gmail.com (JIRA)

unread,
Sep 23, 2015, 10:00:07 PM9/23/15
to jenkinsc...@googlegroups.com

Yes, which is why synchronous steps were mentioned when using @NonCPS as the current implementation already fails with basic Groovy:

@com.cloudbees.groovy.cps.NonCPS
def doAssertNoCPS() {
  // no error when CPS disabled
  assert [1, 2, 3].collect { it } == [1, 2, 3]
}
def doAssertCPS() {
  // fails because CPS transformation results in '4'
  assert [4, 5, 6].collect { it } == [4, 5, 6]
}

doAssertNoCPS()
doAssertCPS()

To be more relevant with current issue, it prevents such direct Groovy approach:

// won't retrieve parameter value as result of 'find' is inconsistent
currentBuild.rawBuild.getAction(hudson.model.ParametersAction).parameters.find { it.name == 'FOO' }.value

eholzwarth@littlegreensoftware.com (JIRA)

unread,
Nov 3, 2015, 5:32:03 PM11/3/15
to jenkinsc...@googlegroups.com

I'm not understanding the workaround, apparently. I tried adding the NonCPS annotation as follows:

		@com.cloudbees.groovy.cps.NonCPS 
		def targetsNotYetDeployed = config.deployTargets.findAll{ !it.hasProperty("deployed") }
		def done = (targetsNotYetDeployed.size() == 0)

But this still throws:

groovy.lang.MissingMethodException: No signature of method: java.lang.Boolean.size() is applicable for argument types: () values: []
Possible solutions: is(java.lang.Object), find(), find(groovy.lang.Closure), with(groovy.lang.Closure), sleep(long), use([Ljava.lang.Object;)
	at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:55)
	at org.codehaus.groovy.runtime.callsite.PojoMetaClassSite.call(PojoMetaClassSite.java:46)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
	at com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:15)
	at WorkflowScript.flow(WorkflowScript:52)
	at WorkflowScript.run(WorkflowScript:91)
	at ___cps.transform___(Native Method)
	...

How can I work around this?

Thanks

jglick@cloudbees.com (JIRA)

unread,
Nov 3, 2015, 5:44:02 PM11/3/15
to jenkinsc...@googlegroups.com

@NonCPS is a method annotation. You cannot apply it to a local variable definition.

jglick@cloudbees.com (JIRA)

unread,
Nov 19, 2015, 4:18:02 PM11/19/15
to jenkinsc...@googlegroups.com
Jesse Glick updated an issue
 
Jenkins / Bug JENKINS-26481
Change By: Jesse Glick
Labels: kohsuke-plane-project

scm_issue_link@java.net (JIRA)

unread,
Mar 31, 2016, 4:45:02 PM3/31/16
to jenkinsc...@googlegroups.com
SCM/JIRA link daemon commented on Bug JENKINS-26481
 
Re: Mishandling of binary methods accepting Closure

Code changed in jenkins
User: Jesse Glick
Path:
cps/src/test/java/org/jenkinsci/plugins/workflow/SerializationTest.java
http://jenkins-ci.org/commit/workflow-plugin/07f36024c20fb900c99de6d02d7d0acef6f62b5a
Log:
JENKINS-26481 Creating integration test.

scm_issue_link@java.net (JIRA)

unread,
Apr 4, 2016, 12:45:10 PM4/4/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Jesse Glick
Path:

src/main/java/org/jenkinsci/plugins/scriptsecurity/sandbox/groovy/SandboxInterceptor.java
src/main/resources/org/jenkinsci/plugins/scriptsecurity/sandbox/whitelists/generic-whitelist
src/test/java/org/jenkinsci/plugins/scriptsecurity/sandbox/whitelists/StaticWhitelistTest.java
http://jenkins-ci.org/commit/script-security-plugin/db50903978f66acc38e6ba6f679601499e3542bc
Log:
JENKINS-26481 When delegating to DefaultGroovyMethods, check the whitelist against that method, but then do not interfere with actual call processing.

scm_issue_link@java.net (JIRA)

unread,
Apr 4, 2016, 12:45:11 PM4/4/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/org/jenkinsci/plugins/scriptsecurity/sandbox/groovy/SandboxInterceptor.java
src/main/resources/org/jenkinsci/plugins/scriptsecurity/sandbox/whitelists/generic-whitelist
src/test/java/org/jenkinsci/plugins/scriptsecurity/sandbox/whitelists/StaticWhitelistTest.java

scm_issue_link@java.net (JIRA)

unread,
Apr 4, 2016, 1:55:02 PM4/4/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Jesse Glick
Path:

cps/pom.xml
cps/src/test/java/org/jenkinsci/plugins/workflow/SerializationTest.java
http://jenkins-ci.org/commit/workflow-plugin/b356799f09d18b0d9f96c1084354df072b7d656f
Log:
JENKINS-26481 With new script-security and groovy-cps releases, eachClosure finally passes.

Compare: https://github.com/jenkinsci/workflow-plugin/compare/a990468a828e...b356799f09d1

scm_issue_link@java.net (JIRA)

unread,
Apr 4, 2016, 3:01:09 PM4/4/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Jesse Glick
Path:
cps/pom.xml

cps/src/main/java/org/jenkinsci/plugins/workflow/cps/persistence/IteratorHack.java
cps/src/test/java/org/jenkinsci/plugins/workflow/SerializationTest.java
http://jenkins-ci.org/commit/workflow-plugin/5b102a5b06745b1eeeb7c1305096bf80e37c1a90
Log:
Merge pull request #372 from jenkinsci/eachClosure-JENKINS-26481

JENKINS-26481 JENKINS-27421 Fix ArrayList$Itr, and integration test for Object.each(Closure)

Compare: https://github.com/jenkinsci/workflow-plugin/compare/e3906483924d...5b102a5b0674

andrew.bayer@gmail.com (JIRA)

unread,
Apr 4, 2016, 3:06:03 PM4/4/16
to jenkinsc...@googlegroups.com

I assume additional changes will be needed for, say, collect and collectEntries?

andrew.bayer@gmail.com (JIRA)

unread,
Apr 4, 2016, 3:06:06 PM4/4/16
to jenkinsc...@googlegroups.com
Andrew Bayer edited a comment on Bug JENKINS-26481
I assume additional changes will be needed for, say, collect  and ,  collectEntries , any, every, find, findAll ?

scm_issue_link@java.net (JIRA)

unread,
Apr 5, 2016, 4:33:26 PM4/5/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Jesse Glick
Path:
cps/src/test/java/org/jenkinsci/plugins/workflow/SerializationTest.java
http://jenkins-ci.org/commit/workflow-cps-plugin/f9122193c2099f63ce006f63d619ff3874799cd7


Log:
JENKINS-26481 Creating integration test.

Originally-Committed-As: 07f36024c20fb900c99de6d02d7d0acef6f62b5a

scm_issue_link@java.net (JIRA)

unread,
Apr 5, 2016, 4:33:27 PM4/5/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Jesse Glick
Path:

cps/pom.xml
cps/src/test/java/org/jenkinsci/plugins/workflow/SerializationTest.java
http://jenkins-ci.org/commit/workflow-cps-plugin/03650953a2c28412f57d0ea6e32aee6a0a937c69


Log:
JENKINS-26481 With new script-security and groovy-cps releases, eachClosure finally passes.

Originally-Committed-As: b356799f09d18b0d9f96c1084354df072b7d656f

jglick@cloudbees.com (JIRA)

unread,
Apr 5, 2016, 4:42:02 PM4/5/16
to jenkinsc...@googlegroups.com

I assume additional changes will be needed for…

Yes, but see issue 7.

scm_issue_link@java.net (JIRA)

unread,
Apr 6, 2016, 6:31:06 PM4/6/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Jesse Glick
Path:
pom.xml
src/test/java/org/jenkinsci/plugins/workflow/SerializationTest.java
http://jenkins-ci.org/commit/workflow-cps-plugin/b5c85d9f1663b1c34c8e56b656fd0e2cee662869
Log:
[FIXED JENKINS-34064] Backing out JENKINS-26481 fix since it broke Pipeline in Jenkins 2.x.

scm_issue_link@java.net (JIRA)

unread,
Apr 6, 2016, 6:32:01 PM4/6/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Jesse Glick
Path:
pom.xml
src/test/java/org/jenkinsci/plugins/workflow/SerializationTest.java

JENKINS-34064 Backing out JENKINS-26481 fix

jglick@cloudbees.com (JIRA)

unread,
Apr 6, 2016, 6:39:03 PM4/6/16
to jenkinsc...@googlegroups.com

Backed out in workflow-cps 2.1.

sradi@web.de (JIRA)

unread,
Apr 15, 2016, 7:22:02 AM4/15/16
to jenkinsc...@googlegroups.com

This issue also ocurrs in the current Jenkins 2.0 release candidate

sradi@web.de (JIRA)

unread,
Apr 15, 2016, 7:32:02 AM4/15/16
to jenkinsc...@googlegroups.com
Stefan Rademacher edited a comment on Bug JENKINS-26481

batmat@batmat.net (JIRA)

unread,
Apr 15, 2016, 10:15:02 AM4/15/16
to jenkinsc...@googlegroups.com

Stefan Rademacher the Jenkins version is not really the relevant part, can you check the versions of the installed plugins, more precisely those called pipeline-* or workflow-*?

And even more precisely, the version of the workflow-cps plugin?

Thanks

sradi@web.de (JIRA)

unread,
Apr 18, 2016, 5:23:04 AM4/18/16
to jenkinsc...@googlegroups.com

There is no *-cps plugin installed in my Jenkins 2.0 release candidate. That's why I mentioned, that this error also occurs in Jenkins 2.0.
The other pipeline plugins have the following versions:
Pipeline 2.0
Pipeline: API 2.0
Pipeline: Basic Steps 2.0
Pipeline: Build Step 2.0
Pipeline: Groovy 2.1
Pipeline: Input Step 2.0
Pipeline: Job 2.1
Pipeline: Multibranch 2.1
Pipeline: Nodes and Processes 2.0
Pipeline: REST API Plugin 1.3
Pipeline: SCM Step 2.0
Pipeline: Shared Groovy Libraries 2.0
Pipeline: Stage Step 2.0
Pipeline: Stage View Plugin 1.3
Pipeline: Step API 2.0

nirish.okram@gmail.com (JIRA)

unread,
Apr 25, 2016, 6:51:06 PM4/25/16
to jenkinsc...@googlegroups.com

Using latest pipeline plugin(s) of 2.1. The below code worked once with the iteration. And it stopped (strange) why only once.

node('win-slave4') {
checkout([$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'CleanBeforeCheckout']], submoduleCfg: [], userRemoteConfigs: [[credentialsId: 'cca9c557-2-9176-f78d91c22907', url: 'g...@github.com:someProjects/testopy.git']]])

def paths = ['folder1', 'folder2', 'folder3']
def dirs = ['dst1', 'dst2', 'dst3']

[paths, dirs].transpose().each { pd ->
def path = pd[0]
def dir = pd[1]
bat "xcopy %cd%
$

{path}

C:
$

{dir}

/E /Y /V"
}
}

nirish.okram@gmail.com (JIRA)

unread,
Apr 25, 2016, 6:52:02 PM4/25/16
to jenkinsc...@googlegroups.com
Niristotle Okram edited a comment on Bug JENKINS-26481

nirish.okram@gmail.com (JIRA)

unread,
Apr 25, 2016, 6:53:02 PM4/25/16
to jenkinsc...@googlegroups.com

nirish.okram@gmail.com (JIRA)

unread,
Apr 25, 2016, 6:53:05 PM4/25/16
to jenkinsc...@googlegroups.com

nirish.okram@gmail.com (JIRA)

unread,
Apr 25, 2016, 6:54:03 PM4/25/16
to jenkinsc...@googlegroups.com

nirish.okram@gmail.com (JIRA)

unread,
Apr 25, 2016, 6:54:06 PM4/25/16
to jenkinsc...@googlegroups.com
Niristotle Okram updated an issue
 
Change By: Niristotle Okram
Comment:
Using latest pipeline plugin(s) of 2.1. The below code worked once with the iteration. And it stopped (strange) why only once. 

node('win-slave4') {
checkout([$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'CleanBeforeCheckout']], submoduleCfg: [], userRemoteConfigs: [[credentialsId: 'cca9c557-2-9176-f78d91c22907', url: 'g...@github.com:someProjects/testopy.git']]])

def paths = ['folder1', 'folder2', 'folder3']
def dirs = ['dst1', 'dst2', 'dst3']

[paths, dirs].transpose().each { pd ->
    def path = pd[0]
    def dir = pd[1]
    bat "xcopy %cd%\\${path} C:\\${dir} /E /Y /V"
    }
  }

pranspach@gmail.com (JIRA)

unread,
Apr 29, 2016, 8:34:02 PM4/29/16
to jenkinsc...@googlegroups.com
Patrick Ranspach commented on Bug JENKINS-26481
 
Re: Mishandling of binary methods accepting Closure

Can we add this to the epic: 2.0: Pipeline as Code? This seems very important to using Groovy in a pipeline as code. It can be easily reproduced and blocks dependable groovy functionality.

Also relevant labels: 2.0, 2.0-planned, testfest, windows, workflow

Maybe also related, I'm only able to access closure arguments within returned closures if I copy the argument:

def test = { name ->
    def path = 'services/' + name
    return { _ ->
        println(name)
        // .. do something
    }
}

will print the same 'name' with this code:

def options = [];
['test', 'test1', 'test2'].each {
    iter ->
        options << test(iter)
}
options.each {it()}
return options

In a Jenkins Pipeline I have to save the argument, like:

def test = { arg ->
    def name = arg;
    def path = 'services/' + name
    return { _ ->
        println(name)
        // .. do something
    }
}

jglick@cloudbees.com (JIRA)

unread,
Jun 6, 2016, 10:03:13 AM6/6/16
to jenkinsc...@googlegroups.com
Jesse Glick updated an issue
 
Change By: Jesse Glick
Labels: groovy kohsuke-plane-project

jglick@cloudbees.com (JIRA)

unread,
Jun 6, 2016, 10:03:13 AM6/6/16
to jenkinsc...@googlegroups.com
Jesse Glick commented on Bug JENKINS-26481
 
Re: Mishandling of binary methods accepting Closure

Stefan Rademacher the current display name of the workflow-cps plugin is Pipeline: Groovy.

Patrick Ranspach be assured that developers are well aware of this issue and are struggling to find a fix. Your “maybe related” sounds unrelated to me, perhaps JENKINS-33468.

scm_issue_link@java.net (JIRA)

unread,
Jun 10, 2016, 8:54:06 AM6/10/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/org/jenkinsci/plugins/workflow/cps/GroovyClassLoaderWhitelist.java
src/main/java/org/jenkinsci/plugins/workflow/cps/SandboxContinuable.java
src/test/java/org/jenkinsci/plugins/workflow/SerializationTest.java
http://jenkins-ci.org/commit/workflow-cps-plugin/efeee2b5a86ca2a5f03efd48fc2c1e596c57e2a2
Log:
JENKINS-26481 Fail the script meaningfully when it attempts to pass a CPS-transformed closure to a binary method.

scm_issue_link@java.net (JIRA)

unread,
Jun 10, 2016, 8:54:13 AM6/10/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/org/jenkinsci/plugins/workflow/cps/GroovyClassLoaderWhitelist.java

src/test/java/org/jenkinsci/plugins/workflow/SerializationTest.java
http://jenkins-ci.org/commit/workflow-cps-plugin/6ad4d04e3df379836cfa8e32072007ab8e59c3a7
Log:
JENKINS-26481 Limit the error to cases where the binary method actually requested a Closure, and is thus likely to try to call it.

scm_issue_link@java.net (JIRA)

unread,
Jun 10, 2016, 8:54:25 AM6/10/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Jesse Glick
Path:

src/test/java/org/jenkinsci/plugins/workflow/cps/steps/RestartingLoadStepTest.java
http://jenkins-ci.org/commit/workflow-cps-plugin/4266f0ce6b1d1eb07fd4c273592d938cf95bfd23
Log:
JENKINS-26481 Verifying that we can still pass closures to functions defined in load’d scripts.

scm_issue_link@java.net (JIRA)

unread,
Jun 10, 2016, 8:54:27 AM6/10/16
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Jesse Glick
Path:

src/main/java/org/jenkinsci/plugins/workflow/cps/GroovyClassLoaderWhitelist.java
src/main/java/org/jenkinsci/plugins/workflow/cps/SandboxContinuable.java
src/test/java/org/jenkinsci/plugins/workflow/SerializationTest.java
src/test/java/org/jenkinsci/plugins/workflow/cps/steps/RestartingLoadStepTest.java
http://jenkins-ci.org/commit/workflow-cps-plugin/004392892aaec46c5d5a541c30e3230a175fcfb2
Log:
Merge pull request #15 from jglick/report-JENKINS-26481

JENKINS-26481 More clearly report problem passing closures to binary methods

Compare: https://github.com/jenkinsci/workflow-cps-plugin/compare/7364fe748099...004392892aae

jglick@cloudbees.com (JIRA)

unread,
Aug 29, 2016, 1:24:17 PM8/29/16
to jenkinsc...@googlegroups.com
Jesse Glick updated an issue
Change By: Jesse Glick
Component/s: workflow-cps-plugin
Component/s: pipeline
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

marcus.a.philip@gmail.com (JIRA)

unread,
Sep 27, 2016, 8:27:06 AM9/27/16
to jenkinsc...@googlegroups.com
Marcus Philip commented on Bug JENKINS-26481
 
Re: Mishandling of binary methods accepting Closure

I get stack trace below when I have this code. I assume it's the same problem.

def keys = []
keys.add('key1')
int afterKeyIndex = keys.findIndexOf { it == 'key1' }
int index = 1 + afterKeyIndex

In some strange way afterKeyIndex is a boolean!

hudson.remoting.ProxyException: groovy.lang.MissingMethodException: No signature of method: java.lang.Integer.plus() is applicable for argument types: (java.lang.Boolean) values: [true]
Possible solutions: plus(java.lang.Number), plus(java.lang.Character), plus(java.lang.String), abs(), is(java.lang.Object), minus(java.lang.Number)
	at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:55)
	at org.codehaus.groovy.runtime.callsite.PojoMetaClassSite.call(PojoMetaClassSite.java:46)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
	at com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:16)
	at netent.JenkinsWtfListMap.addAfter(file:/var/lib/jenkins/jobs/ngp-ddds-application-master/builds/213/libs/netentNGPCoreLib/src/netent/JenkinsWtfListMap.groovy:35)
	at BuildConfig.run(/var/lib/jenkins/jobs/ngp-ddds-application-master/builds/213/libs/netentNGPCoreLib/vars/netentPipelineDsl.groovy:110)
	at WorkflowScript.run(WorkflowScript:23)
	at netentPipelineDsl.runCD(/var/lib/jenkins/jobs/ngp-ddds-application-master/builds/213/libs/netentNGPCoreLib/vars/netentPipelineDsl.groovy:141)
	at ___cps.transform___(Native Method)
	at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:48)
	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
	at sun.reflect.GeneratedMethodAccessor826.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
	at com.cloudbees.groovy.cps.impl.LocalVariableBlock$LocalVariable.get(LocalVariableBlock.java:33)
	at com.cloudbees.groovy.cps.LValueBlock$GetAdapter.receive(LValueBlock.java:30)
	at com.cloudbees.groovy.cps.impl.LocalVariableBlock.evalLValue(LocalVariableBlock.java:22)
	at com.cloudbees.groovy.cps.LValueBlock$BlockImpl.eval(LValueBlock.java:55)
	at com.cloudbees.groovy.cps.LValueBlock.eval(LValueBlock.java:16)
	at com.cloudbees.groovy.cps.Next.step(Next.java:58)
	at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:154)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:33)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:30)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:30)
	at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:164)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:324)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:78)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:236)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:224)
	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:47)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112)
	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

It seems I can solve this by encapsulating keys.findIndexOf in a NonCPS method.

nickolay.rumyantsev@emc.com (JIRA)

unread,
Sep 27, 2016, 9:43:07 AM9/27/16
to jenkinsc...@googlegroups.com

Marcus Philip, you are correct, this is the same issue. From my observations it always return the first result of the closure, in your case it's a boolean result of "it == 'key1'". @NonCPS should help you.

marcus.a.philip@gmail.com (JIRA)

unread,
Sep 28, 2016, 2:27:06 AM9/28/16
to jenkinsc...@googlegroups.com

The absolute irony in this is that I actually wrote unit tests for this code, something I always strive to do but often fail to. This time I could do it because I was writing 'shared code' that did not call step functions. The docs state: "At the base level, any valid Groovy code is OK". Well, I don't know about that ...

Solution: Provide a unit-testing framework that mangles your code the same way that it will be mangled in Jenkins.

BTW, you really should give names to the different variants of shared libraries so we can reason and talk about them.

s+jenkins@varupenne.net (JIRA)

unread,
Oct 12, 2016, 12:57:12 PM10/12/16
to jenkinsc...@googlegroups.com

I have a problem with pipeline. It says it's this problem :

[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (build-modules)
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
java.lang.UnsupportedOperationException: Calling public static java.util.Map org.codehaus.groovy.runtime.DefaultGroovyMethods.eachWithIndex(java.util.Map,groovy.lang.Closure) on a CPS-transformed closure is not yet supported (JENKINS-26481); encapsulate in a @NonCPS method, or use Java-style loops
	at org.jenkinsci.plugins.workflow.cps.GroovyClassLoaderWhitelist.checkJenkins26481(GroovyClassLoaderWhitelist.java:90)
	at org.jenkinsci.plugins.workflow.cps.GroovyClassLoaderWhitelist.permitsStaticMethod(GroovyClassLoaderWhitelist.java:60)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:92)
	at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:149)
	at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:146)
	at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:16)
	at WorkflowScript.run(WorkflowScript:19)
	at ___cps.transform___(Native Method)
	at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:48)
	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
	at sun.reflect.GeneratedMethodAccessor972.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
	at com.cloudbees.groovy.cps.impl.ClosureBlock.eval(ClosureBlock.java:46)
	at com.cloudbees.groovy.cps.Next.step(Next.java:58)
	at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:154)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:33)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:30)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:30)
	at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:163)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:324)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:78)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:236)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:224)
	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:63)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112)
	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Finished: FAILURE

here is my groovy pipeline code :

Unable to find source-code formatter for language: groovy. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml 
node {
    stage('build-modules') {
        def modules = [ 'FINANCE' : 'std-module-FINANCE-5_N9-4_manuel',
                        'MOBILITE' : 'std-module-MOBILE-dev_integration-continue'
                        ]
        def buildMods = [:]

        modules.eachWithIndex { module , i ->
            buildMods["mod${i}"] = {
                println "${module.key} will build ${module.value}"
            }
        }
        parallel buildMods
    }
}

s+jenkins@varupenne.net (JIRA)

unread,
Oct 12, 2016, 12:59:03 PM10/12/16
to jenkinsc...@googlegroups.com
I have a problem with pipeline. It says it's this problem :
{noformat}
{noformat}


here is my groovy pipeline code :
{code: groovy java }

node {
    stage('build-modules') {
        def modules = [ 'FINANCE' : 'std-module-FINANCE-5_N9-4_manuel',
                     'MOBILITE' : 'std-module-MOBILE-dev_integration-continue'
                     ]
        def buildMods = [:]

        modules.eachWithIndex { module , i ->
            buildMods["mod${i}"] = {
                println "${module.key} will build ${module.value}"
            }
        }
        parallel buildMods
    }
}
{code}

jglick@cloudbees.com (JIRA)

unread,
Oct 12, 2016, 2:18:03 PM10/12/16
to jenkinsc...@googlegroups.com

You cannot use eachWithIndex or similar methods currently, sorry.

jglick@cloudbees.com (JIRA)

unread,
Oct 20, 2016, 10:06:04 AM10/20/16
to jenkinsc...@googlegroups.com

Idea to be tested: rather than using DGMPatcher, see if the use syntax can override DefaultGroovyMethods, possibly offering a solution for JENKINS-27421 as well. The problem is a bit of a chicken-and-egg: DefaultGroovyMethods.use(Object, Class, Closure) itself cannot be properly invoked.

jglick@cloudbees.com (JIRA)

unread,
Oct 20, 2016, 10:32:09 AM10/20/16
to jenkinsc...@googlegroups.com

Perhaps could have the CPS engine call GroovyCategorySupport private methods on a predefined category. use itself actually cannot work in a CPS transform; it would have to be applied to the whole CPS VM thread. Or perhaps DGMPatcher can be rewritten to use the tricks done in GroovyCategorySupport: DefaultMetaClassInfo.disabledStandardMC, VMPluginFactory.getPlugin().invalidateCallSites(), etc.

kenorb@gmail.com (JIRA)

unread,
Oct 22, 2016, 10:41:59 PM10/22/16
to jenkinsc...@googlegroups.com
kenorb commented on Bug JENKINS-26481

Same here, I've Multi-line String Parameter (Params) with item like: Foo, Bar, Baz

Then I'm trying to run this code:

Params.split("\\r?\\n").each { param ->
    print "Param: ${param}"
}

Then I've got the error:

java.lang.UnsupportedOperationException: Calling public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.each(java.lang.Object,groovy.lang.Closure) on a CPS-transformed closure is not yet supported (JENKINS-26481); encapsulate in a @NonCPS method, or use Java-style loops

kenorb@gmail.com (JIRA)

unread,
Oct 23, 2016, 2:05:17 AM10/23/16
to jenkinsc...@googlegroups.com
kenorb edited a comment on Bug JENKINS-26481
Same here, I've _Multi-line String Parameter_ (Params) with item multi items like: Foo, Bar, Baz


Then I'm trying to run this code:

{code:java}

Params.split("\\r?\\n").each { param ->
    print "Param: ${param}"
}
{code}


Then I've got the error:

bq. java.lang.UnsupportedOperationException: Calling public static java.lang.Object org.codehaus.groovy.runtime.DefaultGroovyMethods.each(java.lang.Object,groovy.lang.Closure) on a CPS-transformed closure is not yet supported (JENKINS-26481); encapsulate in a @NonCPS method, or use Java-style loops
bq.

ryan.campbell@gmail.com (JIRA)

unread,
Jan 3, 2017, 11:25:11 AM1/3/17
to jenkinsc...@googlegroups.com
recampbell updated an issue
 
Change By: recampbell
Labels: groovy kohsuke-plane-project pipeline-hangs

my_name_is_marat@mail.ru (JIRA)

unread,
Mar 29, 2017, 1:49:06 PM3/29/17
to jenkinsc...@googlegroups.com
Marat S commented on Bug JENKINS-26481
 
Re: Mishandling of binary methods accepting Closure

Is there any workaround for this issue? What is the deadline for solving this issue?
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

my_name_is_marat@mail.ru (JIRA)

unread,
Mar 29, 2017, 1:51:26 PM3/29/17
to jenkinsc...@googlegroups.com
Marat S updated an issue
 
Change By: Marat S
Priority: Major Critical

murashandme@gmail.com (JIRA)

unread,
Jul 10, 2019, 10:34:05 AM7/10/19
to jenkinsc...@googlegroups.com
Ulad Muraveika commented on Bug JENKINS-26481
 
Re: Mishandling of binary methods accepting Closure

Guys, it will be cool if you update documentation on https://jenkins.io/doc/pipeline/examples/ page, because bug was fixed and doc right now is confusing novice users

>Due to limitations in Workflow - i.e., JENKINS-26481 - it's not really possible to use Groovy closures or syntax that depends on closures, so you can't do the Groovy standard of using .collectEntries on a list and generating the steps as values for the resulting entries. You also can't use the standard Java syntax for For loops - i.e., "for (String s: strings)" - and instead have to use old school counter-based for loops.
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

jglick@cloudbees.com (JIRA)

unread,
Jul 10, 2019, 12:05:05 PM7/10/19
to jenkinsc...@googlegroups.com

Ulad Muraveika good catch. Could you file an issue for this in the WEBSITE project? Of course if you have the time to do it, we welcome PRs updating documentation. (In the case of code samples, this means testing that the proposed syntax actually works in current releases.)

bmathus+ossjira@cloudbees.com (JIRA)

unread,
Jul 16, 2019, 10:40:04 AM7/16/19
to jenkinsc...@googlegroups.com

Ulad Muraveika or anyone having the time to fix this, please note that https://jenkins.io is fully backed by https://github.com/jenkins-infra/jenkins.io, so a PR there is the only thing needed to fix it.

(Side note: not only guys can fix this issue )

murashandme@gmail.com (JIRA)

unread,
Jul 17, 2019, 4:35:05 AM7/17/19
to jenkinsc...@googlegroups.com

Baptiste Mathus, I'll do this, because I had funny time with digging around NonSerializable exceptions and have created small documentation file with all such cases for my team. Now it is time to share it

Thanks for additional info and reminder!

ilatypov@yahoo.ca (JIRA)

unread,
Jul 23, 2019, 10:50:09 AM7/23/19
to jenkinsc...@googlegroups.com

Another limit is still annoying because it silently returns from a NonCPS method calling a CPS method.

 

    @NonCPS
    public static String readCurrentVersion(String fileContent) {
        def xml = new XmlSlurper().parseText(Strings.deBOM(fileContent))
        String retval = "${xml.metadata.version}"
        xml = null
        return retval
    }

    // Omitted @NonCPS here
    public static CharSequence deBOM(CharSequence s) {
        [...]
        return s
    }

Calling updateMyXML from the above unexpectedly returned the entire fileContent.  This is probably another unexpected behaviour but seems worth mentioning in the documentation.

 

ilatypov@yahoo.ca (JIRA)

unread,
Jul 23, 2019, 10:51:16 AM7/23/19
to jenkinsc...@googlegroups.com
Ilguiz Latypov edited a comment on Bug JENKINS-26481
Another limit is still annoying because it silently returns from a NonCPS method calling a CPS method.

 
{code:java}

    @NonCPS
    public static String readCurrentVersion(String fileContent) {
        def xml = new XmlSlurper().parseText(Strings.deBOM(fileContent))
        String retval = "${xml.metadata.version}"
        xml = null
        return retval
    }

    // Omitted @NonCPS here
    public static CharSequence deBOM(CharSequence s) {
        [...]
        return s
    }
{code}
Calling updateMyXML readCurrentVersion from the above unexpectedly returned the entire fileContent.  This is probably another unexpected behaviour but seems worth mentioning in the documentation.

 

ilatypov@yahoo.ca (JIRA)

unread,
Jul 23, 2019, 10:51:50 AM7/23/19
to jenkinsc...@googlegroups.com
Ilguiz Latypov edited a comment on Bug JENKINS-26481
Another limit is still annoying because it silently returns from a NonCPS method calling a CPS method.

 
{code:java}
    @NonCPS
    public static String readCurrentVersion(String fileContent) {
        def xml = new XmlSlurper().parseText( Strings.
deBOM(fileContent))

        String retval = "${xml.metadata.version}"
        xml = null
        return retval
    }

    // Omitted @NonCPS here
    public static CharSequence deBOM(CharSequence s) {
        [...]
        return s
    }
{code}
Calling readCurrentVersion from the above unexpectedly returned the entire fileContent.  This is probably another unexpected behaviour but seems worth mentioning in the documentation.

 

jglick@cloudbees.com (JIRA)

unread,
Jul 23, 2019, 11:38:05 AM7/23/19
to jenkinsc...@googlegroups.com

Ilguiz Latypov this ought to have been addressed (in the form of a warning) by JENKINS-31314.
Reply all
Reply to author
Forward
0 new messages