Seems that the error format is totally different. Is this a new pylint version with different output format? Or are warnings still reported correctly? Here is the test case for the current format:

trunk/src/python/cachedhttp.py:3: [C] Line too long (85/80)
trunk/src/python/tv.py:28: [C0103, Show.__init__] Invalid name "seasonCount" (should match [a-z_][a-z0-9_]{2,30}$)
trunk/src/python/tv.py:35: [C0111, Episode] Missing docstring

Can you please add an example with both warnings and errors? Note that the error format has no associated file in the message, should the filename be empty? Where do the numbers after the error refer to?

I am using pylint 1.3.1

The new format from at least from 1.0 appears to be: (where {C} is the one letter indication of the message category)

{C}:{line:3d},{column:2d}: {msg} ({symbol})

Output:
   Using the default text output, the message format is :
  MESSAGE_TYPE: LINE_NUM:[OBJECT:] MESSAGE
  There are 5 kind of message types :
  * (C) convention, for programming standard violation
  * (R) refactor, for bad code smell
  * (W) warning, for python specific problems
  * (E) error, for much probably bugs in the code
  * (F) fatal, if an error occurred which prevented pylint from doing
  further processing.

Here is example output from the pylint page:

************* Module pylint.checkers.format
W: 50: Too long line (86/80)
W:108: Operator not followed by a space
     print >>sys.stderr, 'Unable to match %r', line
            ^
W:141: Too long line (81/80)
W: 74:searchall: Unreachable code
W:171:FormatChecker.process_tokens: Redefining built-in (type)
W:150:FormatChecker.process_tokens: Too many local variables (20/15)
W:150:FormatChecker.process_tokens: Too many branches (13/12)

I will change my message format to the pre-1.0 message format in the meantime.

It appears there used to be an option --output-format=parseable which gave the format you are expecting, but it has been deprecated. It generates the following error:

UserWarning: parseable output format is deprecated. This is equivalent to --msg-template={path}:{line}: [{msg_id}({symbol}), {obj}] {msg}

I see. One problem with the new format: the path is missing in the parsed line. If the section header should be scanned (e.g., ************* Module tests.api.utils.client) then the single line parser cannot be used anymore

I think there are two options:

1. Create a new parser for the new file format (interested in providing a pull request?)
2. Don't change the parser and add a note so that users will pick the correct command line option. And ask the maintainer of pylint why this option has been deprecated.

What do you think?

I just ended up requiring my various projects to include the following snippet in there pylintrc. It seems to be working well.

[REPORTS]
output-format=text
reports=no
msg-template=

:

: [

(

),

]

Another possible improvement here might be to do some basic content validation within your parser, and if it seems like the content of the log file being parsed doesn't meet the format specification you expect you could provide some kind of helpful feedback to the user, something to the effect of "pylint output not in the expected format. See online documentation for details of the expected format."

I know this would have been greatly helpful to me since I just spent the last several hours messing with my Python code and Jenkins plugins trying to get this to work and at no point did any of these tools indicate a potential configuration problem.

For reference, just in case anyone comes across this defect who may be trying to integrate output with this plugin from "epylint", called from within another python script, here's a trick I found to get it working.

As mentioned on the pylint website, you would typically make such a call using some code that looks something like this:

from pylint import epylint as lint
lint.py_run("MyFile.py")

However, for some reason this method will ignore some of the settings found in the pylintrc file as well as command line parameters provided to the py_run() method. This includes the 'msg-template' property mentioned above. After looking into the implementation of the py_run() method I noticed that the script essentially offloads it's work to an external console tool which defaults to "epylint" (epylint.bat on Windows). It seems that this command line tool is what is to blame for this odd behavior... but I won't get into the details of that here.

Suffice it to say, typically users will use the "pylint" (pylint.bat on Windows) on the shell rather than this epylint tool. Information on the differences between these two tools is sparse at best, but I've discovered that if you use the same parameters when calling the more conventional 'pylint' tool everything works as expected. Luckily, the run_py() method allows you to overload the command line tool used when offloading the work, so we can easily redirect it to this more conventional script using code something like this:

from pylint import epylint as lint
lint.py_run("MyFile.py", script="pylint")

Making this minor adjustment, and ensuring your associated pylintrc file has the 'msg-template' declaration Chris mentions above, should result in a workable solution for this plugin.

Thanks for the detailed feedback. Currently there is no possibility to pre-validate an input file. I think this could be added as optional step for each parser and if the validation fails then a corresponding warning could be shown.

Hello!

I've also stumbled across the same issue. I've tried using the configuration proposed by powellchristoph, but to no avail.

I'm using Jenkins 2.91 and Warnings Plugin 4.64 and PyLint 1.7.4.

My .pylintrc (or at least its interesting part) looks as follows:

msg-template={path}: {line}: [{msg_id} ({symbol}), {obj}] {msg}
output-format=text
reports=no
score=yes

The SCA-related pipeline fragment:

withPythonEnv("python3") {
    pysh(script: "python -m pip install -r requirements.txt")
    pysh(script: "python -m pylint ${env.WORKSPACE} > pylint_status.log", returnStatus: true)
}
warnings(canResolveRelativePaths: false, canRunOnFailed: true, failedNewAll: '5', failedTotalAll: '500',
    failedTotalHigh: '5', failedTotalLow: '300', failedTotalNormal: '200', healthy: '0',
    parserConfigurations: [[parserName: 'PyLint', pattern: 'pylint_status.log']], unHealthy: '500',
    unstableNewAll: '0', unstableTotalAll: '100', unstableTotalHigh: '0', unstableTotalLow: '80',
    unstableTotalNormal: '20', usePreviousBuildAsReference: true)

And while I get a lot of warnings & errors from PyLint, Warnings still says that there're no errors and no duplicates (MY_WORKSPACE_PATH is, of course, my edit):

[WARNINGS] Parsing warnings in files 'pylint_status.log' with parser PyLint
[WARNINGS] Searching for all files in *MY_WORKSPACE_PATH* that match the pattern pylint_status.log
[WARNINGS] Parsing 1 file in *MY_WORKSPACE_PATH*
[WARNINGS] Successfully parsed file *MY_WORKSPACE_PATH*/pylint_status.log with 0 unique warnings and 0 duplicates.
Skipping warnings blame since pipelines do not have an SCM link.%n
[WARNINGS] Computing warning deltas based on reference build #1 Score: 6.94/10.0
[WARNINGS] Plug-in Result: Success - no threshold has been exceeded

The warnings graph shows a steady 0 warnings.

My questions are:

1. What is the proper message format for PyLint to work with Warnings?
2. Can it be documented somewhere?
3. Do I have to disable PyLint's report for it to work?

ljbd: This is the supported format (from the test case): https://github.com/jenkinsci/analysis-model/blob/master/src/test/resources/edu/hm/hafner/analysis/parser/pyLint.txt

This issue here is about errors not detected, warnings seem to get parsed quite well. 

based on drulli's reference of ljbd above, here is the message format, pylint command, Pipeline step and console output that worked for Jenkins to report pylint messages through the Warnings plugin:

./pylintrc contains:

 msg-template={path}:{line}: [{msg_id}, {obj}] {msg} ({symbol})

Command:

pylint --rcfile=./pylintrc CODE > pylint.log

Pipeline:

step([$class: 'WarningsPublisher',
  parserConfigurations: [[
    parserName: 'PyLint', pattern: '**/pylint*.log'
  ]],
  unstableTotalAll: '0', 
  usePreviousBuildAsReference: true
])

Console:

[WARNINGS] Parsing warnings in files '**/pylint-*.log' with parser PyLint
[WARNINGS] Searching for all files in WORKSPACE that match the pattern **/pylint-*.log
[WARNINGS] Parsing 1 file in WORKSPACE
[WARNINGS] Successfully parsed file WORKSPACE/pylint-py36.log with 2 unique warnings and 0 duplicates.

I updated the help in the PyLint tool description.