Los scripts Jenkins CI Pipeline no pueden usar el método groovy.lang.GroovyObject

Estoy usando Jenkins 2 para compilar proyectos Java, quiero leer la versión de un pom.xml, estaba siguiendo este ejemplo:

https://github.com/jenkinsci/pipeline-plugin/blob/master/TUTORIAL.md

El ejemplo sugiere:

Parece que hay algún problema de seguridad al acceder al sistema de archivos, pero no puedo entender qué está dando (o por qué) ese problema:

Solo estoy haciendo un poco diferente al ejemplo:

def version() {
    String path = pwd();
    def matcher = readFile("${path}/pom.xml") =~ '<version>(.+)</version>'
    return matcher ? matcher[0][1] : null
}

El error que obtengo al ejecutar el método de 'versión':

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)

Estoy usando estas versiones: Plugin Pipeline 2.1 Jenkins 2.2

Arreglo rapido

Tuve un problema similar y lo resolví haciendo lo siguiente

1. Vaya a jenkins> Administrar jenkins> Aprobación de script en proceso
2. Había un comando pendiente, que tuve que aprobar.

Alternativa 1: deshabilitar la zona de pruebas

Como este artículo explica en profundidad, los scripts maravillosos se ejecutan en modo sandbox de forma predeterminada. Esto significa que un subconjunto de métodos maravillosos puede ejecutarse sin la aprobación del administrador. También es posible ejecutar scripts que no estén en modo sandbox, lo que implica que todo el script debe ser aprobado por un administrador a la vez. Esto evita que los usuarios aprueben cada línea en ese momento.

Se pueden ejecutar scripts sin sandbox desmarcando esta casilla de verificación en la configuración de su proyecto justo debajo de su script:

Alternativa 2: deshabilitar la seguridad del script

Como se explica en este artículo , también es posible deshabilitar la seguridad del script por completo. Primero instale el complemento de seguridad de script permisivo y luego cambie su archivo jenkins.xml agregue este argumento:

-Dpermissive-script-security.enabled = true

Entonces, jenkins.xml se verá así:

<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>

¡Asegúrese de saber lo que está haciendo si implementa esto!

Tienes que deshabilitar la caja de arena para Groovy en la configuración de tu trabajo.

Actualmente, esto no es posible para proyectos de múltiples ramas donde el script maravilloso proviene de scm. Para obtener más información, consulte https://issues.jenkins-ci.org/browse/JENKINS-28178

Me encontré con esto cuando reduje el número de parámetros de entrada de usuario en userInput de 3 a 1. Esto cambió el tipo de salida variable de userInput de una matriz a una primitiva.

Ejemplo:

myvar1 = userInput['param1']
myvar2 = userInput['param2']

a:

myvar = userInput

Para sortear el sandboxing de los scripts Groovy almacenados en SCM, recomiendo ejecutar el script como Groovy Command (en lugar del archivo Groovy Script ):

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)

en tal caso, la secuencia de comandos maravillosa se transfiere del espacio de trabajo al Jenkins Master, donde se puede ejecutar como system Groovy Script. El sandboxing se suprime siempre que la opción Use Groovy Sandbox no esté marcada .