sono d'accordo con @dmeister, ma con il codice di condotta (Jenkinsfile) Suggerisco un try/catch e quindi analizzando l'errore. In questo modo è possibile determinare se si sta solo ricevendo bit di stato da pylint (vedi la documentazione pylint), sia pylint segnala un errore di utilizzo, o se c'è stata una catastrofica venga meno
try {
sh 'pylint --output-format=parseable my_module'
} catch (pylint_rc) {
// pylint_rc will be of the form
// "hudson.AbortException: script returned exit code NN"
// where NN is 1-63 and represents bit field;
// bits 0-4 indicate lint-ish issues in analyzed code,
// bit 5 indicates pylint usage error
echo "pylint_rc= \'$pylint_rc\'"
String rc = "$pylint_rc"
String code = rc.split()[5]
echo "Isolated return code string value $code"
int value = code.toInteger()
// catastrophic/crash error returns a 1; else there is a pylint return code
int error_bits_code = value & 0x20
int lint_bits_code = value & 0x1f
echo "pylint error_bits_code=$error_bits_code ; lint_bits_code=$lint_bits_code"
if ((value == 1) || (error_bits_code != 0)) {
currentBuild.result = "FAILURE"
throw pylint_rc
}
}
Scuse a Groovy puristi - Groovy non è la mia cosa, quindi sono sicuro che questo può essere migliorato - fammi sapere. Esiste un buco noto: se pylint rileva solo errori di tipo "fatale" (bit 0) e nessun altro problema di alcun tipo (i bit 1-4 non sono impostati), questo codice genera erroneamente un'eccezione. Ma il mio codice contrassegna tonnellate di problemi, quindi non è un problema per me. La correzione (? Parse error msg?) Potrebbe essere banale per qualcuno con costolette groovy.
fonte
2017-07-28 18:47:33
Dannatamente dritto. Ho eseguito il debug di lint.py e ho scoperto una chiamata sys.exit (self.linter.msgstatus) in cui il msgstatus non è stato trovato nel contesto. Sostituendo questo con uno 0 ha funzionato e ora le build stanno succedendo. – Gobliins