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

Estoy usando Jenkins 2 para comstackr proyectos de 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:

Tubería completa de Jenkins con una función problemática en un círculo

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

Solo estoy haciendo un poco diferente al ejemplo:

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

El error que obtengo al ejecutar el método ‘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. Navegue a jenkins> Gestionar jenkins> Aprobación de script en proceso
  2. Había un comando pendiente, que tuve que aprobar.

Enlace de aprobación del proceso en Jenkins 2.61 Alternativa 1: deshabilitar sandbox

Como este artículo explica en profundidad, las secuencias de comandos groovy se ejecutan en modo de espacio aislado de forma predeterminada. Esto significa que un subconjunto de métodos groovy puede ejecutarse sin la aprobación del administrador. También es posible ejecutar scripts que no estén en el modo de espacio aislado, lo que implica que toda la secuencia de comandos debe ser aprobada por un administrador a la vez. Esto impide que los usuarios aprueben cada línea en el momento.

La ejecución de scripts sin sandbox se puede hacer desactivando esta checkbox en la configuración del proyecto justo debajo del script: enter image description here

Alternativa 2: deshabilitar la seguridad del script

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

-Dpermissive-script-security.enabled = true

Entonces, jenkins.xml tendrá el siguiente aspecto:

 ..bin\java -Dpermissive-script-security.enabled=true -Xrs -Xmx4096m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "%BASE%\jenkins.war" --httpPort=80 --webroot="%BASE%\war" 

¡Asegúrate de saber lo que estás haciendo si implementas esto!

Debe desactivar el sandbox para Groovy en la configuración de su trabajo.

Actualmente esto no es posible para proyectos multibranquios en los que Groovy Script proviene de scm. Para obtener más información, consulte https://issues.jenkins-ci.org/browse/JENKINS-28178.

Para evitar el entorno aislado de 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 groovy se transfiere desde el espacio de trabajo al Jenkins Master, donde se puede ejecutar como un system Groovy Script . La zona de pruebas se suprime siempre que el uso de Sandbox Groovy no esté marcado .

Intereting Posts