2016-05-16 7 views
14

Ich habe Code ähnlich die unten in meinem Jenkinsfile:try/catch/finally Masken Jenkinsfile Probleme bei groovy Compiler Ausnahmen

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

Wenn der obige Code wegen einiger jenkins-Pipeline Fehler nicht in Das try { } (z. B. mit nicht genehmigte statische Methode) das Skript schlägt im Hintergrund fehl. Wenn ich den try/catch entferne/kann ich endlich die Fehler sehen. Mache ich etwas falsch? Sollte error die Pipeline-Fehler in dem Protokoll nicht erneut angezeigt werden?

EDIT: Ich habe es geschaffen, das Problem zu groovy Syntax zu, wenn z.B. Ich benutze eine Variable, die noch nicht zugewiesen wurde. Beispiel: echo foo Wenn foo nirgendwohin deklariert/zugewiesen wird, wird Jenkins den Build nicht ausführen und den Grund nicht anzeigen, wenn es sich in try/catch/finally befindet, was die Ausnahme erneut auslöst.

+0

Wenn diese Ebene Groovy waren, ja, es wäre gearbeitet habe, sondern weil dies ein starkes DSL ist, kann der DSL-Läufer tun, was es mit Ausnahme will ... Vielleicht sollten Sie versuchen, diese stattdessen: 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-carrierror-code-catch-error-and-set-build-result schlägt vor, dass try/catch/finally auch funktionieren sollte –

+0

Richtig, aber wenn du dieses Problem hast sieht es nicht so aus ... – Renato

Antwort

4

Dies geschieht, wenn eine zusätzliche Ausnahme innerhalb des finally Blocks oder vor dem erneuten Werfen innerhalb catch geworfen wird. In diesen Fällen wird die verschluckt und script-security fängt es nicht ein.

+0

Keine Ausnahme wird schließlich innen geworfen, weil es richtig funktioniert, wenn ich die störende Linie im Versuchblock entferne. –

+0

Dann muss es vor dem Re-Wurf ins Innenfischen kommen. – amuniz

+0

Nein, leicht reproduzierbar, wenn das groovige Skript z.B. eine nicht deklarierte Variable. Es gibt keinen Ausnahme-Stack-Trace, wenn ich try/catch entferne/schließlich bekomme ich den Stack-Trace. –

Verwandte Themen