sonar.testExecutionReportPaths is not working at module level

Get help SonarQube
, ,
#1

I’ve a multi module maven project with a parent containing 2 child as follows

parent
|
| - frontend
| - backend

The frontend module is a mavenized reactjs project, and backend is a java project.

I’m using jest-sonar-reporter in the frontend module which generates the test-report.xml

The issue - the test-report.xml is only read by sonar scanner if the below property is configured at parent project.

<sonar.testExecutionReportPaths>frontend/coverage/test-report.xml</sonar.testExecutionReportPaths>

If I configure it to the frontend module then the report is not being read by scanner and unit test for frontend projects are not shown on the sonar dashboard.

sonar.testExecutionReportPaths property should be supported at the module level. Defining the module report paths in parent project is simply a violation of modularity principle.

sonar.testExecutionReportPaths not triggering the sensor when run from a gradle subproject
#2

Hey there.

I moved this to Get Help as this is known behavior.

As a part of the drop of modules back in SonarQube v7.6 (MMF-365 ), we changed the generic coverage/test reports sensors to be global sensors (SONAR-11530), meaning they only run once for the project (and not for each module).

This means that, for example, users who have sonar.testExecutionReportPaths set in a module’s pom.xml file will no longer have Test Execution data reported.

Feel free to make a suggestion if you think this should be changed (or i can move this thread there). It’s not something we’ve gotten a lot of feedback on.

#4

Hi Colin, Thanks for the reply. Let me explain my view on this.

First, MMF-365 is very confusing in terms of making a clear distinction about what the word modules means there. Its mentioned - drop the concept of module in SQ/SC So I’m assuming its only related to dropping the module functionality at SQ/SC

Also while looking in detail I’ve found this page Release Upgrade Notes which clearly states that

Concept of module removed from the UI
This version drops the concept of module from the interface
…
For the most part (see below) analysis of multi-module projects will continue to work as it has.

Second, “we changed the generic coverage/test reports sensors to be global sensors” - Why?
I can confirm that below properties are still supported at the module level

sonar.sources
sonar.tests
sonar.javascript.lcov.reportPaths

If these are supported at module level then why not sonar.testExecutionReportPaths ?

Third, Is bit funny but I was checking the SonarJS repository and I have found the below code in this pom file - SonarJS/pom.xml at master · SonarSource/SonarJS · GitHub

  <properties>
    <!--  this is necessary because of drop of modules  -->
    <sonar.testExecutionReportPaths>eslint-bridge/test-report.xml</sonar.testExecutionReportPaths>

See the comment, presence of that comment justifies that it should actually belong to the module level.

Forth, and final, I think reverse mapping child modules properties in the parent project is not a good practice. so I believe this needs to be fixed.

Sorry for this big reply, I would love to hear your thoughts on this. Thanks

#5

To be honest, this topic doesn’t really interest me too deeply, I just had the facts :smiley: I’ll ping somebody who might be able to answer the Why? a little more authoritatively.

#7

Thanks :slight_smile:
Please move this thread to suggestions if you could.

BTW, found similar post but for gradle, adding link below for reference