SonarScanner on Bazel build locks up at "DEBUG: Using pattern 'coverage-reports/*coverage-*.xml' to find reports"

  • versions used

SonarQube Enterprise Edition Version 8.9 (build 43852)
SonarScanner 4.6.2.2472
Java 1.8.0_312 Red Hat, Inc. (64-bit)
Linux 3.10.0-1127.el7.x86_64 amd64

  • error observed

SonarScanner locks up at:

21:26:26.020 INFO: Sensor Cobertura Sensor for Python coverage [python]
21:26:26.020 DEBUG: Using pattern 'coverage-reports/*coverage-*.xml' to find reports
  • steps to reproduce
    Use Bazel as your build system, run SonarQube. Bazel generates a build/ directory with thousands of symlinks, and this causes the search for ‘coverage-reports/coverage-.xml’ to lock up.

FWIW, I can run:

$ time find . -name '*coverage-*.xml'

real	0m0.476s
user	0m0.243s
sys	0m0.233s

… and that returns no results in nothing flat.

  • potential workaround

If I remove the build/ directory SonarScanner will quickly determine that there is no file that matches the pattern and continue on. As long as the build/ directory is there SonarScanner will lock up.

Other things I tried:

  • Ignore the build and external directories with:
sonar.exclusions=**/build/**/*,**/extern/**/*,**/external/**/*

This excludes the build/ directory from the source code scan (good) but Cobertura Sensor for Python coverage still checks the build/ directory for the *coverage-*.xml file and locks up (bad).

  • Disable cobertura with:
sonar.maven.test.skip
sonar.cobertura.skip=true

or

sonar.maven.test.skip=true
sonar.cobertura.skip=true

or

maven.test.skip
cobertura.skip=true

or

maven.test.skip=true
cobertura.skip=true

… but none of these disable the scan for the *coverage-*.xml file so the scan still locks up.

  • Hard code an absolute path

I tried hard-coding an absolute path for:

sonar.python.coverage.reportPaths=/tmp/no-such-file.xml

So that the scanner would just look there for the xml file, fail to find it, and move on. Even with an absolute path specified the Cobertura Sensor for Python coverage still checks the build/ directory for the *coverage-*.xml file and locks up.

The only thing I’ve found so far that works is to remove the build directory, but that’s where all of the build files are.

1 Like

In my Jenkins pipeline, SonarQube works perfectly fine if I run it before we run our build. The code gets analyzed, tests pass, the QG is green.

If I run it after our build SonarScan hangs as I described above.

if I rsync the source directory from ${workspace}/BFCore/ to ${workspace}/BFCore.sonar/ and omit the ${workspace}/BFCore/build/ directory, I can analyze ${workspace}/BFCore.sonar/ and SonarScan no longer hangs, but then the withSonarQubeEnv{} block DOES NOT EXIT.

I added echo "SonarScan completed" after Sonarscan, and echo "Wait for SonarQube results" after the closing brace of withSonarQubeEnv{}. I can see the “SonarScan completed” output in Jenkins, but it never prints out “Wait for SonarQube results”, it just sits there. If I strace the Jenkins process it appears to be stuck in some sort of a FUTEX loop, possibly waiting for something that never happens.

I need to run it after the build if I want to analyze C++ code.

I eventually “fixed” the problem by removing all symlinks from the build directory just prior to running SonarScan.

I’m not sure why cobertura locks up if there are symlinks present. Based on strace data it looks like cobertura goes into some sort of infinite loop, possibly because one or more symlinks point to a parent directory and cobertura keeps following the links in a loop.