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.
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
@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 –
Giusto, ma se hai questo problema sembra che non sia ... – Renato