[JIRA] (JENKINS-59667) CpsCallableInvocation.checkMismatch with @NonCPS method calling simply groovy getter (not steps)

1 view
Skip to first unread message

dicomj23@gmail.com (JIRA)

unread,
Oct 4, 2019, 2:53:02 PM10/4/19
to jenkinsc...@googlegroups.com
Dicom J created an issue
 
Jenkins / Bug JENKINS-59667
CpsCallableInvocation.checkMismatch with @NonCPS method calling simply groovy getter (not steps)
Issue Type: Bug Bug
Assignee: Andrew Bayer
Components: workflow-cps-plugin
Created: 2019-10-04 18:52
Priority: Minor Minor
Reporter: Dicom J

The following document provides an example how to handle native NonCPS methods like toString.

https://wiki.jenkins.io/display/JENKINS/Pipeline+CPS+method+mismatches#PipelineCPSmethodmismatches-Overridesofnon-CPS-transformedmethods

class Test {
  @Override
  public String toString() {
    return "Test"
  }
}
def builder = new StringBuilder()
builder.append(new Test())
echo(builder.toString()) 

 

But this example is way to trivial, as toString in 99,99% returns variable information usually provided by a couple of handy methods of the class, like in this case with CPS getFullName method

class Test {
    String name

    Test(String name) {
        this.name = name
    }

    String getFullName() {
        return 'some prefix ' + name
    }

    @NonCPS
    @Override
    public String toString() {
        return this.fullName
    }

}

def builder = new StringBuilder()
builder.append(new Test('foobar'))
echo(builder.toString())

Previously this code worked as it doesn't call any steps as the document suggest, but now it started to raise 

java.lang.IllegalStateException: expected to call java.lang.StringBuilder.append but wound up catching Test.getFullName; see: https://jenkins.io/redirect/pipeline-cps-method-mismatches

Obviously it's possible to put in @NonCPS for getFullName but that simply means that almost all methods by default must be @NonCPS, and only those that call steps must be CPS ones.

Can we have this 
'org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService.handleMismatch'
properly fixed as there's actually no mismatch, as even explicit toString

(new Test('foobar')).toString() 

doesn't help to work this around?

 

Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages