Jenkins pipeline throws reporting:org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException - jenkins

Jenkins pipeline throws
reporting:org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException:
Scripts not permitted to use method groovy.util.XmlSlurper parseText
java.lang.String
Here is the code:
def testsuites = new XmlSlurper().parseText(xml)
Also I could not see this method in ScriptApproval. How can we whitelist this method manually or any other solution to fix this?

I've tested your use case with Jenkins 2.60.3 and after running a script that uses new XmlSlurper().parseText(someXml) I get expected exception:
org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use method groovy.util.XmlSlurper parseText java.lang.String
at org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectMethod(StaticWhitelist.java:175)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:137)
at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:155)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:159)
at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:17)
at WorkflowScript.run(WorkflowScript:9)
And I see in /scriptApproval I can approve it:
You can always try adding this approval manually. In Jenkins home directory you can find scriptApproval.xml file. Add:
<string>method groovy.util.XmlSlurper parseText java.lang.String</string>
inside <approvedSignatures> tag and restart Jenkins. It will cause the same effect as approving this signature via Jenkins UI.

Related

"Scripts not permitted to use field hudson.util.Secret value" when passing a password parameter to a downstream job in a Jenkinsfile [duplicate]

I am Using Jenkins 2 for compiling Java Projects, I want to read the version from a pom.xml, I was following this example:
https://github.com/jenkinsci/pipeline-plugin/blob/master/TUTORIAL.md
The example suggest:
It seems that there is some security problem accessing the File System but I can't figure out what it is giving (or why) that problem:
I am just doing a little bit different than the example:
def version() {
String path = pwd();
def matcher = readFile("${path}/pom.xml") =~ '<version>(.+)</version>'
return matcher ? matcher[0][1] : null
}
The Error I am getting when running the 'version' method :
org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use method groovy.lang.GroovyObject invokeMethod java.lang.String java.lang.Object (org.codehaus.groovy.runtime.GStringImpl call org.codehaus.groovy.runtime.GStringImpl)
at org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectMethod(StaticWhitelist.java:165)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:117)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:103)
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:15)
at WorkflowScript.run(WorkflowScript:71)
at ___cps.transform___(Native Method)
at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:55)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:106)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:79)
at sun.reflect.GeneratedMethodAccessor408.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:100)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:79)
at sun.reflect.GeneratedMethodAccessor408.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:106)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:79)
at sun.reflect.GeneratedMethodAccessor408.invoke(Unknown Source)
I am using these versions:
Plugin Pipeline 2.1
Jenkins 2.2
Quickfix Solution:
I had similar issue and I resolved it doing the following
Navigate to jenkins > Manage jenkins > In-process Script Approval
There was a pending command, which I had to approve.
Alternative 1: Disable sandbox
As this article explains in depth, groovy scripts are run in sandbox mode by default. This means that a subset of groovy methods are allowed to run without administrator approval. It's also possible to run scripts not in sandbox mode, which implies that the whole script needs to be approved by an administrator at once. This preventing users from approving each line at the time.
Running scripts without sandbox can be done by unchecking this checkbox in your project config just below your script:
Alternative 2: Disable script security
As this article explains it also possible to disable script security completely. First install the permissive script security plugin and after that change your jenkins.xml file add this argument:
-Dpermissive-script-security.enabled=true
So you jenkins.xml will look something like this:
<executable>..bin\java</executable>
<arguments>-Dpermissive-script-security.enabled=true -Xrs -Xmx4096m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "%BASE%\jenkins.war" --httpPort=80 --webroot="%BASE%\war"</arguments>
Make sure you know what you are doing if you implement this!
You have to disable the sandbox for Groovy in your job configuration.
Currently this is not possible for multibranch projects where the groovy script comes from the scm. For more information see https://issues.jenkins-ci.org/browse/JENKINS-28178
I ran into this when I reduced the number of user-input parameters in userInput from 3 to 1. This changed the variable output type of userInput from an array to a primitive.
Example:
myvar1 = userInput['param1']
myvar2 = userInput['param2']
to:
myvar = userInput
To get around sandboxing of SCM stored Groovy scripts, I recommend to run the script as Groovy Command (instead of Groovy Script file):
import hudson.FilePath
final GROOVY_SCRIPT = "workspace/relative/path/to/the/checked/out/groovy/script.groovy"
evaluate(new FilePath(build.workspace, GROOVY_SCRIPT).read().text)
in such case, the groovy script is transferred from the workspace to the Jenkins Master where it can be executed as a system Groovy Script. The sandboxing is suppressed as long as the Use Groovy Sandbox is not checked.
To get the version of a maven project, I usually use mvn binary in the sh block as follows. No need for admin permissions.
stage("Compile") {
steps {
sh """
mvn help:evaluate -Dexpression=project.version -q -DforceStdout > version.txt
"""
}
}
Following #JavaTechnical's answer herein a Maven project's version can be assigend to a variable:
stage("getPomProjectVersion") {
steps {
...
def pomProjectVersion = sh script: 'mvn help:evaluate -Dexpression=project.version -q -DforceStdout', returnStdout: true
...
}
}
The issue I had was that the Groovy object didn't have the function I was attempting to call. To my understanding if Groovy can't find the function then Groovy starts to do introspection on the object looking for for the undefined object, which caused this error.
So check to make sure that the function you are trying to call really exists.
Unrelated to OP's issue; But this Stack Overflow Question pops up on top of search.
I was getting this error when I tried to declare a variable named owner (re-declare apparently) in my pipeline script. Changed it to repoOwner and the script worked as expected.

Running groovy script at the end of Jenkins Job

I need to run a groovy Post-Build script to do some clean up so I have arranged the following script:
def sout = new StringBuilder(), serr = new StringBuilder()
def proc = '/usr/bin/docker stop mysql'.execute()
proc.consumeProcessOutput(sout, serr)
proc.waitForOrKill(1000)
Although the command '/usr/bin/docker stop mysql' works if I log on the machine, when the groovy script is executed, the following error is raised:
java.io.IOException: Cannot run program "/usr/bin/docker": error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
at java.lang.Runtime.exec(Runtime.java:620)
at java.lang.Runtime.exec(Runtime.java:450)
at java.lang.Runtime.exec(Runtime.java:347)
at org.codehaus.groovy.runtime.ProcessGroovyMethods.execute(ProcessGroovyMethods.java:533)
at org.codehaus.groovy.runtime.dgm$894.invoke(Unknown Source)
at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:274)
at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:157)
at org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:23)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:104)
at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:155)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:159)
at org.kohsuke.groovy.sandbox.impl.Checker$checkedCall$0.callStatic(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:56)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:194)
at Script1.run(Script1.groovy:2)
Do you know why the groovy engine fails to find the 'docker' command?
Thanks!
The Groovy Postbuild plugin actually runs on the master, not on the build node. The documentation states:
This plugin executes a groovy script in the Jenkins JVM
which is presumably meant to convey "and not in an agent JVM". (Fun side note: If you use println in the Groovy script, it prints out to the Jenkins master log, not to the job's console log)
The Post build task plugin does run on the build node (and you don't need to wrap your shell command in a groovy script). The task requires a condition: to "always run" your script just leave the Log text blank.
You might also consider taking a look at the Jenkins Pipeline, which lets you bake in try/catch type logic and maintain your pipeline "as code" using a Jenkinsfile.

How to import and run 3rd party Jenkins Plugin's extension DSL (githubPullRequest) with Gradle tool locally?

I'm a newbie at Jenkins job-dsl scripting.
I'm working to convert the Jenkins XML configuration to Groovy DSL script using a plugin (https://github.com/AOEpeople/gradle-jenkins-job-dsl-plugin) that uses Gradle tool for building the script and running Unit Test locally.
However, currently, I'm facing an issue with the extension DSL from a 3rd Party Jenkins Plugin (https://github.com/jenkinsci/ghprb-plugin).
triggers {
githubPullRequest {
orgWhitelist("Test")
cron("H/5 * * * *")
extensions {
commitStatus {
completedStatus('SUCCESS', 'Build succeeded.')
completedStatus('FAILURE', 'Build failed.')
}
}
}
}
The script cannot be generated by Gradle because of the issue:
Expected no exception to be thrown, but got 'javaposse.jobdsl.dsl.DslScriptException'
at spock.lang.Specification.noExceptionThrown(Specification.java:119)
at com.aoe.gradle.jenkinsjobdsl.JobScriptsSpec.test DSL script #file.name(JobScriptsSpec.groovy:55)
Caused by: javaposse.jobdsl.dsl.DslScriptException: (PullRequestJobTemplate.groovy, line 59) No signature of method: static org.apache.commons.lang.ClassUtils.isAssignable() is applicable for argument types: ([Ljava.lang.Class;, [Ljava.lang.Class;, java.lang.Boolean) values: [[class com.unified.dsl.templates.PullRequestJobTemplate$_closure1$_closure5$_closure15], ...]
Possible solutions: isAssignable([Ljava.lang.Class;, [Ljava.lang.Class;), isAssignable(java.lang.Class, java.lang.Class)
at javaposse.jobdsl.dsl.AbstractDslScriptLoader.runScriptEngine(AbstractDslScriptLoader.groovy:107)
at javaposse.jobdsl.dsl.AbstractDslScriptLoader.runScripts_closure1(AbstractDslScriptLoader.groovy:60)
at groovy.lang.Closure.call(Closure.java:414)
at groovy.lang.Closure.call(Closure.java:430)
at javaposse.jobdsl.dsl.AbstractDslScriptLoader.runScripts(AbstractDslScriptLoader.groovy:46)
at javaposse.jobdsl.dsl.AbstractDslScriptLoader.runScript(AbstractDslScriptLoader.groovy:81)
at com.aoe.gradle.jenkinsjobdsl.JobScriptsSpec.test DSL script #file.name(JobScriptsSpec.groovy:51)
Caused by: groovy.lang.MissingMethodException: No signature of method: static org.apache.commons.lang.ClassUtils.isAssignable() is applicable for argument types: ([Ljava.lang.Class;, [Ljava.lang.Class;, java.lang.Boolean) values: [[class com.unified.dsl.templates.PullRequestJobTemplate$_closure1$_closure5$_closure15], ...]
Possible solutions: isAssignable([Ljava.lang.Class;, [Ljava.lang.Class;), isAssignable(java.lang.Class, java.lang.Class)
at javaposse.jobdsl.plugin.ExtensionPointHelper.findExtensionPoints_closure1(ExtensionPointHelper.groovy:24)
at javaposse.jobdsl.plugin.ExtensionPointHelper.findExtensionPoints(ExtensionPointHelper.groovy:23)
at javaposse.jobdsl.plugin.JenkinsJobManagement.callExtension(JenkinsJobManagement.java:365)
at javaposse.jobdsl.dsl.AbstractExtensibleContext.methodMissing(AbstractExtensibleContext.groovy:17)
at com.unified.dsl.templates.PullRequestJobTemplate.closure1$_closure5(PullRequestJobTemplate.groovy:59)
at com.unified.dsl.templates.PullRequestJobTemplate.closure1$_closure5(PullRequestJobTemplate.groovy)
at javaposse.jobdsl.dsl.ContextHelper.executeInContext(ContextHelper.groovy:16)
at javaposse.jobdsl.dsl.Job.triggers(Job.groovy:568)
at com.unified.dsl.templates.PullRequestJobTemplate$_closure1.doCall(PullRequestJobTemplate.groovy:58)
at groovy.lang.Closure.call(Closure.java:414)
at groovy.lang.Closure.call(Closure.java:430)
at groovy.lang.Closure.call(Closure.java:430)
at javaposse.jobdsl.dsl.JobParent.processItem(JobParent.groovy:114)
at javaposse.jobdsl.dsl.JobParent.freeStyleJob(JobParent.groovy:47)
at com.unified.dsl.base.JobBuilder.build(JobBuilder.groovy:52)
at stage.script.run(script:12)
at javaposse.jobdsl.dsl.AbstractDslScriptLoader.runScript(AbstractDslScriptLoader.groovy:124)
at javaposse.jobdsl.dsl.AbstractDslScriptLoader.runScriptEngine(AbstractDslScriptLoader.groovy:101)
... 6 more
So the stacktrace you are getting is being generated by the Spock Test that checks to see if the job-dsl script compiles. So you have set up your development environment correctly! Always a good start.
Now all you need to do is setup your local Jenkins runtime to allow the Jenkins XML config file to be generated when it is kicked off by the Spock Test.
Reviewing your job-dsl script I must say it looks good to me. Specifically I compared it to the complete sample job-dsl on the GitHub pull request builder plugin's home page ...
https://wiki.jenkins.io/display/JENKINS/GitHub+pull+request+builder+plugin#GitHubpullrequestbuilderplugin-JobDSLSupport
The key part of the stack trace is this line here
PullRequestJobTemplate.groovy, line 59) No signature of method:
static org.apache.commons.lang.ClassUtils.isAssignable() is applicable
for argument types: ([Ljava.lang.Class;, [Ljava.lang.Class;,
java.lang.Boolean) values: [[class com.unified.dsl.templates.PullRequestJobTemplate$_closure1$_closure5$_closure15], ...]
To me this would indicate that there was still a run-time dependency missing to allow the GH PR Builder plugin job-dsl to run as expected.
Further reviewing the plugin page I note that the following dependencies are variously required and optional ...
credentials (version:1.21)
matrix-project (version:1.6)
build-flow-plugin (version:0.12, optional)
ssh-agent (version:1.3)
structs (version:1.6)
github (version:1.26.0)
git (version:2.4.0)
github-api (version:1.82)
plain-credentials (version:1.1)
job-dsl (version:1.39, optional)
token-macro (version:1.10, optional)
If you add these to the Gradle build then I would say that your XML will be generated.
Don't forget to add these dependencies to the target Jenkins server when you have completed your job-dsl development.

Jenkins CI Pipeline Scripts not permitted to use method groovy.lang.GroovyObject

I am Using Jenkins 2 for compiling Java Projects, I want to read the version from a pom.xml, I was following this example:
https://github.com/jenkinsci/pipeline-plugin/blob/master/TUTORIAL.md
The example suggest:
It seems that there is some security problem accessing the File System but I can't figure out what it is giving (or why) that problem:
I am just doing a little bit different than the example:
def version() {
String path = pwd();
def matcher = readFile("${path}/pom.xml") =~ '<version>(.+)</version>'
return matcher ? matcher[0][1] : null
}
The Error I am getting when running the 'version' method :
org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use method groovy.lang.GroovyObject invokeMethod java.lang.String java.lang.Object (org.codehaus.groovy.runtime.GStringImpl call org.codehaus.groovy.runtime.GStringImpl)
at org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectMethod(StaticWhitelist.java:165)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:117)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:103)
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:15)
at WorkflowScript.run(WorkflowScript:71)
at ___cps.transform___(Native Method)
at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:55)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:106)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:79)
at sun.reflect.GeneratedMethodAccessor408.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:100)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:79)
at sun.reflect.GeneratedMethodAccessor408.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:106)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:79)
at sun.reflect.GeneratedMethodAccessor408.invoke(Unknown Source)
I am using these versions:
Plugin Pipeline 2.1
Jenkins 2.2
Quickfix Solution:
I had similar issue and I resolved it doing the following
Navigate to jenkins > Manage jenkins > In-process Script Approval
There was a pending command, which I had to approve.
Alternative 1: Disable sandbox
As this article explains in depth, groovy scripts are run in sandbox mode by default. This means that a subset of groovy methods are allowed to run without administrator approval. It's also possible to run scripts not in sandbox mode, which implies that the whole script needs to be approved by an administrator at once. This preventing users from approving each line at the time.
Running scripts without sandbox can be done by unchecking this checkbox in your project config just below your script:
Alternative 2: Disable script security
As this article explains it also possible to disable script security completely. First install the permissive script security plugin and after that change your jenkins.xml file add this argument:
-Dpermissive-script-security.enabled=true
So you jenkins.xml will look something like this:
<executable>..bin\java</executable>
<arguments>-Dpermissive-script-security.enabled=true -Xrs -Xmx4096m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "%BASE%\jenkins.war" --httpPort=80 --webroot="%BASE%\war"</arguments>
Make sure you know what you are doing if you implement this!
You have to disable the sandbox for Groovy in your job configuration.
Currently this is not possible for multibranch projects where the groovy script comes from the scm. For more information see https://issues.jenkins-ci.org/browse/JENKINS-28178
I ran into this when I reduced the number of user-input parameters in userInput from 3 to 1. This changed the variable output type of userInput from an array to a primitive.
Example:
myvar1 = userInput['param1']
myvar2 = userInput['param2']
to:
myvar = userInput
To get around sandboxing of SCM stored Groovy scripts, I recommend to run the script as Groovy Command (instead of Groovy Script file):
import hudson.FilePath
final GROOVY_SCRIPT = "workspace/relative/path/to/the/checked/out/groovy/script.groovy"
evaluate(new FilePath(build.workspace, GROOVY_SCRIPT).read().text)
in such case, the groovy script is transferred from the workspace to the Jenkins Master where it can be executed as a system Groovy Script. The sandboxing is suppressed as long as the Use Groovy Sandbox is not checked.
To get the version of a maven project, I usually use mvn binary in the sh block as follows. No need for admin permissions.
stage("Compile") {
steps {
sh """
mvn help:evaluate -Dexpression=project.version -q -DforceStdout > version.txt
"""
}
}
Following #JavaTechnical's answer herein a Maven project's version can be assigend to a variable:
stage("getPomProjectVersion") {
steps {
...
def pomProjectVersion = sh script: 'mvn help:evaluate -Dexpression=project.version -q -DforceStdout', returnStdout: true
...
}
}
The issue I had was that the Groovy object didn't have the function I was attempting to call. To my understanding if Groovy can't find the function then Groovy starts to do introspection on the object looking for for the undefined object, which caused this error.
So check to make sure that the function you are trying to call really exists.
Unrelated to OP's issue; But this Stack Overflow Question pops up on top of search.
I was getting this error when I tried to declare a variable named owner (re-declare apparently) in my pipeline script. Changed it to repoOwner and the script worked as expected.

Execute "Publish TestNG results" step in Jenkinsfile

I'm trying to convert an existing set of Jenkins jobs to the new pipeline syntax, and I don't understand how to convert the post-build action "Publish TestNG results". The pipeline syntax page doesn't help as this specific action is not listed, so I've tried the following syntax:
step([$class: 'hudson.plugins.testng.Publisher', reportFilenamePattern: 'test-output/testng-results.xml'])
My assumption being that the class name would have to match the content of config.xml in the current configuration:
<hudson.plugins.testng.Publisher plugin="testng-plugin#1.10">
<reportFilenamePattern>test-output/testng-results.xml</reportFilenamePattern>
<escapeTestDescp>true</escapeTestDescp>
<escapeExceptionMsg>true</escapeExceptionMsg>
<showFailedBuilds>false</showFailedBuilds>
<unstableOnSkippedTests>false</unstableOnSkippedTests>
<failureOnFailedTestConfig>false</failureOnFailedTestConfig>
</hudson.plugins.testng.Publisher>
However, an exception is being thrown when executing the statement :
java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at org.jenkinsci.plugins.structs.describable.DescribableModel.instantiate(DescribableModel.java:193)
at org.jenkinsci.plugins.workflow.steps.StepDescriptor.newInstance(StepDescriptor.java:104)
at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:134)
at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:113)
at groovy.lang.GroovyObject$invokeMethod.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:151)
at org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:21)
at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:115)
at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:149)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:146)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:123)
at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:123)
at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:15)
at WorkflowScript.testBranch(WorkflowScript:71)
So my questions are :
is it possible to trigger any kind of post-job action using the 'step' statement ?
if yes, is there a rule of thumb to find the class name, and attribute names ?
In case that's relevant for the question, I'm running Jenkins 2.8 with all pipeline plugins up to date, and the full Jenkinsfile can be found on GitHub
Publishing TestNG test results is now available in Pipelines.
Use:
step([$class: 'Publisher'])
or with custom location of the result file:
step([$class: 'Publisher', reportFilenamePattern: '**/custom/testng-results.xml'])
According to this comment on Jenkins Jira adding to Pipeline snippet generator is pending.
(tested on Jenkins 2.9.13 and Pipeline plugin 2.4)
At this time, the TestNG Plugin isn't compatible with Pipelines. See JENKINS-27121

Resources