Дженкинс с Пилинтом дает сбой сборки - PullRequest
Новая
       14

Дженкинс с Пилинтом дает сбой сборки

9 голосов
/ 08 сентября 2011

Я добавил шаг сборки для выполнения скрипта Python.
В этом скрипте pylint вызывается с lint.Run (.. args) для проверки кода.
Скрипт работает, но в концесборка завершается с единственным сообщением об ошибке:

Build step 'Execute Python script' marked build as failure

У кого-то есть идея, почему это происходит?

Ответы [ 6 ]

19 голосов
/ 29 января 2012

Вы также можете просто поставить

pylint ||выход 0

в командной строке оболочки.Плагин Pylint все равно провалит сборку, проверив результат pyllint.

13 голосов
/ 08 сентября 2011

Pylint имеет неприятное поведение, чтобы возвращать ненулевой код выхода, даже если обнаружена небольшая проблема с предупреждением. Только когда все в порядке, возвращается 0 (см. Справочную страницу).

Поскольку обычно ненулевой код обозначает ошибку, Дженкинс отказывает в сборке.

Я вижу два пути преодоления этого:

  • Используйте небольшой скрипт вокруг pylint, который всегда возвращает 0. Тогда jenkins не потерпит неудачу из-за pylint. Я использую небольшой скрипт на Python, вызывающий pylint с os.system () и sys.exit (0) после. Вы можете видеть это как переопределение кода ошибки Pylint.
  • Патч Пилинт. Например, в моей системе Linux вызов sys.exit () находится в файле /usr/lib/pymodules/python2.6/pylint/lint.py
3 голосов
/ 03 апреля 2012

В недавнем рилинте есть возможность не вызывать sys exit 

lint.Run(args, exit=False, **kwargs)
2 голосов
/ 01 марта 2019

В Pylint 1.9.3 есть флаг --exit-zero.

https://github.com/PyCQA/pylint/blob/1.9/ChangeLog#L47

2 голосов
/ 08 сентября 2011

Похоже, что ваше выполнение Pylint завершается с ненулевым статусом (отсутствует сценарий, неверные параметры ...), возможно, вы выходите из сценария с вызванным исключением или sys.exit(something_else_than_zero)

0 голосов
/ 28 июля 2017

Я согласен с @dmeister, но с кодом конвейера (Jenkinsfile) я предлагаю попробовать / перехватить и затем проанализировать ошибку. Таким образом, вы можете определить, получаете ли вы только биты состояния от pylint (см. Документы Pylint), сообщает ли pylint об ошибке использования или произошел катастрофический сбой: 

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

Прошу прощения у заводных пуристов - это не мое дело, поэтому я уверен, что это можно улучшить - дайте мне знать. Существует одна известная дыра: если pylint обнаруживает только ошибки «фатального» типа (бит 0) и никаких других проблем любого рода (биты 1-4 не установлены), тогда этот код будет некорректно генерировать исключение. Но мой код помечает кучу проблем, так что это не проблема для меня. Исправление («parse error msg») может быть тривиальным для кого-то с отличными отбивками.

...