Sonar scanner taking 30-50min to find report

Team: we have enterprise license and am running a scan on TypeScript project and scanner spins for like 1-2hrs before completing. we want to avoid that. is there a parameter to set that will avoid this lookup?

see below log. on this line scanner is just spinning and it completes after like 1hr. how can we skip that because my report is not even there it is under here
coverage_file=“bazel-out/_coverage/_coverage_report.dat”

18:33:38.589 DEBUG: Using pattern 'coverage-reports/*coverage-*.xml' to find reports

my sonar-scanner.properties is this



#----- Default SonarQube server
sonar.projectVersion=${env.MAIN_COMMIT_ID}
sonar.branch.name=main
sonar.host.url=http://sonar.sonar.com:9000
sonar.login=${env.SONAR_TOKEN}

#----- Default source code encoding
sonar.sourceEncoding=UTF-8

#coverage reports

#Exclusions
# Define the same root directory for sources and tests

# Include test subdirectories in test scope
sonar.test.inclusions=src/**/test/**/*

# Exclude test subdirectories from source scope
sonar.exclusions=src/**/test/*,src/**/test/**/*,src/**/**/*.tf
#sonar.exclusions=src/services/**/*.tf
sonar.c.file.suffixes=-
sonar.cpp.file.suffixes=-
sonar.objc.file.suffixes=-

scanner is below

        sonar-scanner -X \
            -Dsonar.sources=$infra_sources \
            -Dsonar.tests=$infra_sources \
            -Dsonar.projectName="$project_name" \
            -Dsonar.coverageReportPaths=$coverage_file \
            -Dsonar.projectKey=$project_key

18:33:37.830 INFO: Starting rules execution
18:33:37.830 INFO: 4 source files to be analyzed
18:33:37.842 DEBUG: Not enough content in 'src/cmd/remote-dev/virtual-machine/items/app/simhub/start_webrtc.py' to have CPD blocks, it will not be part of the duplication detection
18:33:38.589 INFO: 4/4 source files have been analyzed
18:33:38.589 INFO: Sensor Python Sensor [python] (done) | time=1881ms
18:33:38.589 INFO: Sensor Cobertura Sensor for Python coverage [python]
18:33:38.589 DEBUG: Using pattern 'coverage-reports/*coverage-*.xml' to find reports

if we see below 17:04 to 17:36 minutes to find report

17:04:09.133 DEBUG: Using pattern 'coverage-reports/*coverage-*.xml' to find reports
17:36:54.346 DEBUG: No report was found for sonar.python.coverage.reportPaths using default pattern coverage-reports/*coverage-*.xml
17:36:54.346 INFO: Sensor Cobertura Sensor for Python coverage [python] (done) | time=1965213ms

again below. so is there a way i can control this to find fast or even skip because there is no python code.

18:33:38.589 INFO: Sensor Python Sensor [python] (done) | time=1881ms
18:33:38.589 INFO: Sensor Cobertura Sensor for Python coverage [python]
18:33:38.589 DEBUG: Using pattern 'coverage-reports/*coverage-*.xml' to find reports
19:05:35.357 DEBUG: No report was found for sonar.python.coverage.reportPaths using default pattern coverage-reports/*coverage-*.xml

Hey there.

What version of SonarQube are you using?

And, what does $infra_sources resolve to? Is it a specific directory – or, for example, your entire file system?

yes it is src

Hey there.

Re-reading your post, I think there’s an easy fix of setting sonar.exclusions=**/*.py, which should prevent the Python sensor(s) from running.

so it will take care of this ? observe last line. how to avoid this? taking 30minutes to find.

10:45:24.077 DEBUG: No report was found for sonar.python.coverage.reportPaths using default pattern coverage-reports/*coverage-*.xml
10:45:24.078 INFO: Sensor Cobertura Sensor for Python coverage [python] (done) | time=2122818ms
10:45:24.078 INFO: Sensor PythonXUnitSensor [python]
10:45:24.078 DEBUG: Using pattern 'xunit-reports/xunit-result-*.xml' to find reports

It should prevent the sensor from running, if there are no Python files.

sorry not clear. what should I set to avoid it? and I do have python files . so if i do sonar.exclusions=**/*.py it will probably skip python files completely. is there a way I can let the it not take so much time?

Sorry, I understood this as a Typescript project.

This is being investigated by our team at this thread here:

Hopefully they’ll have an update to share soon.

If you want to temporarily alleviate the issue, you can add the exclusion (it seems only 4 files will be affected in this project.

Hi @Abdul_Mohammed,

Sorry for the late reply.

While we are investigating the issue could I ask for a full debug log of the scanner? We are trying to figure out if the coverage is the only part of the scanner which is involved, also could you tell me which JDK you are using?
I could not reproduce the issue locally even with several million files, I was wondering if you were using any network disc which could cause the slowness. If it is the case could you try on a local disc and see if the problem still persists?

Thank you,

David