Struggling to get Sonarqube to parse jest content for coverage in a javascript/spring boot project


This is about the paths in your report not matching the paths to the files as SonarQube understand them. Your log excerpt^ is showing up with some bolding. Did you do that on purpose or were there ** pairs in the log you copy/pasted?



[INFO] Parsing /home/jenkins/workspace/decon-web_FinalBuildTest/deconweb/test-report.xml
[INFO] Imported test execution data for 0 files
[INFO] Test execution data ignored for 33 unknown files, including:
[INFO] Sensor Generic Test Executions Report (done) | time=8ms

So now we know the paths in your coverage report (are they really from root?). What do the paths to the files look like as SonarQube understand them? (Hint: you can get that by looking at the file in the SQ UI).


So it does appear that the sonar scanner is reading the absolute path from jenkins as its point of reference to the build workspace but relative pathing to the workspace root works as that is how I resolved the sources issue.

If I look in the scanner context I see the following, which I am not sure is relevant to the issue for the JS tests
It appears the scanner is picking up the full path to the java tests but I see no relevant pathing to the JS tests.
If I look in the SQ UI under the code tab I only see the following so it appears to me that I need to illuminate the scanner to the location of the tests?

Yes, I think so.


So where would that be defined? Whats odd is that the path referenced in the log and the actual path to the tests is the same. So when the log says execution data is ignored for unknown tests. What is actually reporting that?
Can the sonar.tests value support multiple comma delimited values similar to the sonar.source property?



Uhm… You just said that’s not entirely the case:


Very sorry I miss spoke the path to the tests that it is complaining about is accurate, those jest tests do exist in that location. However the sonar.tests value does not include the path to the jest test, only the path to the java tests


Okay, so then overriding it with a value that points to all your tests will likely do the trick. Just to be clear, when it gets information about unknown files (such as your JS tests), SonarQube doesn’t really have anything it can do with that and so the data gets dropped.


First a huge thank you to @ganncamp for her patience and guidance through the resolution. Done in a way that helped me learn along the way and prompted me to investigate and solve rather than listen and apply.

If you have stumbled here and are using maven to build and test your java/js project and SQ is only picking up the java side of the solution for analysis and processing of test/coverage content then read on.

It turns out the solution was quite simple but not obvious (to me) through the docs and various “solutions” online. After the initial configuration of the project, SQ had picked up the full path to my java source and the associated jacoco unit reports. I needed to update the paths to pick up both!

Many solutions referenced updating these in the file, except I didnt have one. As mentioned above by Ann, in a maven environment this can be done in the pom file!

So in order to get sonar to pick up both Java and JS code for analysis I had to update the sonar.sources property to look in multiple places. As configured it was only looking in

Assuming the following
Java source located in its normal location [JenkinsWorkspaceRoot]/src/main/java
JS source located in [JenkinsWorkspaceRoot]/client/src

Adding the properties to my pom to override the initial setting to include both paths to source resolved the scanning issues and adding thesonar.javascript.lcov.reportPaths, testExecutionReportPath and updating the sonar.tests property pointing to my, test-report.xml file and tests respectively resolved the issue with not seeing test coverage and execution reporting for the JS side in the sonar console


Hope this helps anyone else in my boat in the future.


This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.