| We are using a global lib with `vars/pipeline.groovy` in Jenkins 2.32.1 and everything works fine. When using the same lib with Jenkins 2.32.3 we suddenly get failing pipeline builds with this error:
org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use method groovy.lang.GroovyObject invokeMethod java.lang.String java.lang.Object (org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter doTry org.jenkinsci.plugins.workflow.cps.CpsClosure2) at org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectMethod(StaticWhitelist.java:183) 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:16) ...
The `vars/pipeline.groovy` looks as simple as that:
def doStuff() {
echo "hello!"
}
And within our `Jenkinsfile` we call it like that:
node {
stage("do stuff") {
pipeline.doStuff()
}
}
It pretty much looks like a script-security plugin issue on first sight. (this was updated from 1.25 to 1.27 when we use Jenkins 2.32.3). However, after having simplified our `vars/pipeline.groovy` to such a mininmal helper method example there is really nothing that script security should complain about. But it still does throw the exception above. In a desperate move I renamed `vars/pipeline.groovy` to `vars/wat.groovy`, and guess what? It works... So my conclusion is that it must have something to do with either the name `pipeline.groovy`, or simply a variable named `pipeline` being implicitly defined in the global scope with newer Jenkins versions. I'm not sure which component exactly produces the error, so the ones I assigned are the most likely culprits for me. |
