webentwicklung-frage-antwort-db.com.de

try / catch / finally maskiert Jenkinsfile-Probleme bei groovigen Compiler-Ausnahmen

Ich habe einen ähnlichen Code wie den in meiner Jenkins-Datei:

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 aufgrund einiger Fehler im Zusammenhang mit der Jenkins-Pipeline im try { } Fehlschlägt (z. B. unter Verwendung einer nicht genehmigten statischen Methode), schlägt das Skript unbemerkt fehl. Wenn ich den try/catch/finally entferne, kann ich die Fehler sehen. Mache ich etwas falsch? Sollte das erneute Werfen von error nicht dazu führen, dass die Pipeline-Fehler im Protokoll angezeigt werden?

BEARBEITEN: Ich habe es geschafft, das Problem auf eine groovige Syntax zu reduzieren, wenn z. Ich verwende eine Variable, die noch nicht zugewiesen wurde. Beispiel: echo foo Wenn foo an keiner Stelle deklariert/zugewiesen wird, schlägt Jenkins den Build fehl und zeigt den Grund nicht an, wenn er sich innerhalb von try/catch/finally befindet, wodurch die Ausnahme erneut ausgelöst wird.

23

Dies geschieht, wenn eine zusätzliche Ausnahme innerhalb des Blocks finally oder vor dem erneuten Auslösen innerhalb von catch ausgelöst wird. In diesen Fällen wird der RejectedAccessException verschluckt und script-security fängt es nicht.

7
amuniz