Gli script della pipeline CI di Jenkins non sono autorizzati a utilizzare il metodo groovy.lang.GroovyObject

Sto usando Jenkins 2 per compilare progetti Java, voglio leggere la versione da un pom.xml, stavo seguendo questo esempio:

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

L'esempio suggerisce:

Sembra che ci sia qualche problema di sicurezza durante l'accesso al File System ma non riesco a capire cosa sta dando (o perché) quel problema:

Sto solo facendo un po 'di differenza rispetto all'esempio:

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

L'errore che ricevo durante l'esecuzione del metodo "versione":

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)

Sto usando queste versioni: Plugin Pipeline 2.1 Jenkins 2.2

Soluzione rapida

Ho avuto un problema simile e l'ho risolto facendo quanto segue

1. Passa a jenkins> Gestisci jenkins> Approvazione script in-process
2. C'era un comando in sospeso, che ho dovuto approvare.

Alternativa 1: disabilita sandbox

Come questo articolo spiega in dettaglio, gli script groovy vengono eseguiti in modalità sandbox per impostazione predefinita. Ciò significa che un sottoinsieme di metodi groovy può essere eseguito senza l'approvazione dell'amministratore. È anche possibile eseguire script non in modalità sandbox, il che implica che l'intero script deve essere approvato da un amministratore contemporaneamente. Ciò impedisce agli utenti di approvare ogni riga in quel momento.

L'esecuzione di script senza sandbox può essere eseguita deselezionando questa casella di controllo nella configurazione del progetto appena sotto lo script:

Alternativa 2: disabilitare la sicurezza degli script

Come spiega questo articolo, è anche possibile disabilitare completamente la sicurezza degli script. Prima installa il plug-in di sicurezza degli script permissivi e successivamente modifica il tuo file jenkins.xml aggiungi questo argomento:

-Dpermissive-script-security.enabled = true

Quindi il tuo jenkins.xml avrà un aspetto simile a questo:

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

Assicurati di sapere cosa stai facendo se lo implementi!

Devi disabilitare la sandbox per Groovy nella configurazione del tuo lavoro.

Attualmente questo non è possibile per i progetti multibranch in cui lo script groovy proviene da scm. Per ulteriori informazioni, vedere https://issues.jenkins-ci.org/browse/JENKINS-28178

Mi sono imbattuto in questo quando ho ridotto il numero di parametri di input dell'utente in userInput da 3 a 1. Ciò ha cambiato il tipo di output variabile di userInput da un array a una primitiva.

Esempio:

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

per:

myvar = userInput

Per aggirare il sandboxing degli script Groovy archiviati in SCM, consiglio di eseguire lo script come Groovy Command (invece del file 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)

in tal caso, lo script groovy viene trasferito dall'area di lavoro a Jenkins Master dove può essere eseguito come file system Groovy Script. Il sandboxing viene soppresso fintanto che Use Groovy Sandbox non è selezionato .