2016-05-16 10 views
14

Ho codice simile a quello qui sotto nel mio Jenkinsfile:try/catch/finally maschere Jenkinsfile problemi in caso di eccezioni compilatore groove

node { 
    checkout scm 
    // do some stuff 
    try { 
     // do some maven magic 
    } catch (error) { 
     stage "Cleanup after fail" 
     emailext attachLog: true, body: "Build failed (see ${env.BUILD_URL}): ${error}", subject: "[JENKINS] ${env.JOB_NAME} failed", to: '[email protected]' 
     throw error 
    } finally { 
     step $class: 'JUnitResultArchiver', testResults: '**/TEST-*.xml' 
    } 
} 

Se il codice di cui sopra non riesce a causa di alcuni errori Jenkins-gasdotto connessi nella il try { } (ad esempio utilizzando un metodo statico non approvato) lo script non riesce in modo silenzioso. Quando rimuovo il try/catch/finalmente riesco a vedere gli errori. Sto facendo qualcosa di sbagliato? Non dovresti ribollire il numero error e far apparire gli errori della pipeline nel log?

MODIFICA: Sono riuscito a risolvere il problema con la sintassi groovy, quando ad es. Io uso una variabile che non è stata ancora assegnata. Esempio: echo foo Se foo non viene dichiarato/assegnato, Jenkins fallirà la compilazione e non mostrerà il motivo se si trova all'interno di try/catch/finally che rilancia l'eccezione.

+0

Se questo fosse semplice Groovy, sì, avrebbe funzionato, ma poiché questo è un DSL Groovy, il corridore DSL può fare tutto ciò che vuole con l'eccezione ... Forse dovresti provare questo: https: // jenkins.io/doc/pipeline/steps/workflow-basic-steps/#code-error-code-error-signal – Renato

+0

@RenatoBut https://jenkins.io/doc/pipeline/steps/workflow-basic-steps/# code-catcherror-code-catch-error-and-set-build-result Suggerisce che try/catch/finalmente dovrebbe funzionare anche –

+0

Giusto, ma se hai questo problema sembra che non sia ... – Renato

risposta

4

Ciò si verifica quando un'eccezione aggiuntiva viene generata all'interno del blocco finally o prima del rigirarsi all'interno di catch. In questi casi il RejectedAccessException viene ingoiato e lo script-security non lo cattura.

+0

Alla fine non viene lanciata alcuna eccezione, perché funziona correttamente quando rimuovo la riga in questione nel blocco try. –

+0

Quindi deve essere prima del re-throw in catch. – amuniz

+0

No, facilmente riproducibile se lo script groovy utilizza per es. una variabile non dichiarata. Non c'è traccia dello stack di eccezioni, quando rimuovo try/catch/finally ottengo lo stacktrace. –