Closed
Description
Steps to reproduce
python3 -m venv venv
source venv/bin/activate
python --version
pip install pylint
export PYTHONPATH=`pwd`
pylint --exit-zero -j 4 --reports=y -f parseable my_files/ tests/ | tee pylint.out
pylint --exit-zero --reports=y -f parseable my_files/ tests/ | tee pylint.out
pip uninstall pylint
pip install pylint==2.4.4
pylint --exit-zero -j 4 --reports=y -f parseable my_files/ tests/ | tee pylint.out
Current behavior
In Pylint 2.4.4 the summary report including Pylint score was shown even when using the -j option to control the number of cores used.
Expected behavior
I would expect Pylint 2.5.0 to have the same behavior as 2.4.4 with a valid report along with the score being shown. This score not being shown breaks out CI/CD pipeline where we grep for the score to ensure it stays the same or improves.
pylint --version output
(venv) [scharman@foomy_repo]$ pylint --version
pylint 2.5.0
astroid 2.4.0
Python 3.6.8 (default, Aug 7 2019, 17:28:10)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)]
Metadata
Metadata
Assignees
Type
Projects
Relationships
Development
No branches or pull requests
Activity
bgehman commentedon Apr 29, 2020
I'm seeing this problem, and another (bigger) problem with the new 2.5.0 version, coupled with the
-j
(--jobs / aka parallel) execution option. The same violations are repeated whenj>1
. In our TravisCI build engines, where we run on 30+ core machines to rapidly pylint our source (usingj=0
) -- the same pylint violation is now repeated 30+ times.We funnel the pylint report in to our sonarqube system, where our poor dev team is now freaking out that their ~6k violations have mushroomed in to ~180k violations (the same violations repeated/duplicated).
Running with
j=1
is not an option as it takes over 20 min to pylint a project with ~72k LOC.This all worked fine in
2.4.4
. I'm going to lock our CI process to that previous version of pylint until the broken-j / --jobs
issues are fixed...bobbyscharmann commentedon Apr 29, 2020
@bgehman We saw the same exact issue in our build with the -j option and issues being reported multiple times. The solution to getting the report to show (original issue) and the multiple reports was to simply not take advantage of parallel jobs for now.
bgehman commentedon Apr 30, 2020
@bobbyscharmann yeah, I hear ya. For us it simply just takes way too long with -j=1 (the default). Would add an additional 20+ minutes for our builds when not taking advantage of full parallelism.
I'm going with this hack (to lock us to 2.4.4 for now):
PCManticore commentedon May 2, 2020
Thank you, I can reproduce it as well, its definitely a regression.
Fix a regression where the score was not reported with multiple jobs
Fix a regression where the score was not reported with multiple jobs
1 remaining item