2011-09-08 12 views
7

Ho aggiunto un passo di costruzione per eseguire uno script Python.
In questo script pylint viene chiamato con lint.Run (.. args) per controllare il codice.
lo script funziona, ma alla fine, la build non riesce con l'unico messaggio di errore:Jenkins con pylint dà difetto di costruzione

Build step 'Execute Python script' marked build as failure

qualcuno ha un'idea perché questo accade?

risposta

1

sembra che la vostra uscita esecuzione pylint con uno stato diverso da zero (sceneggiatura manca, opzioni cattive ...), forse si esce lo script con un'eccezione sollevata o un sys.exit(something_else_than_zero)

+0

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

11

pylint ha il comportamento sgradevole restituisce un codice di uscita diverso da zero anche se è stato rilevato un piccolo problema di avviso. Solo quando tutto è andato bene, viene restituito 0 (vedi pagina man).

Come di solito un codice diverso da zero denota un errore, Jenkins fallisce la costruzione.

vedo due modi per superare questo:

  • utilizzare un piccolo script intorno pylint che restituisce sempre 0. Poi Jenkins non mancherà a causa di pylint. Io uso un piccolo script python che chiama pylint con os.system() e sys.exit (0) dopo. Puoi vederlo come prioritario del codice di errore di pylint.
  • Distilla patch. Per esempio, sul mio sistema Linux la chiamata sys.exit() è nel file /usr/lib/pymodules/python2.6/pylint/lint.py
+0

Sì, ottima idea. Ci proverò. – Gobliins

+0

Ha funzionato come previsto! – Gobliins

+0

Ho trasmesso l'output a cat, e ora sembra che abbia successo. per esempio. 'pylint -f html code.py | cat> report.html' – zyxue

15

Si può anche semplicemente mettere un

cilindrico || exit 0

nella shell cmdline. Il plugin Pylint fallirà comunque la compilazione controllando il risultato di pyllint.

3

rylint più recenti hanno l'opzione per non chiamare l'uscita sys

lint.Run (args, uscita = false, ** kwargs)

0

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.