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.
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.
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
<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
To be honest, this topic doesn’t really interest me too deeply, I just had the facts I’ll ping somebody who might be able to answer the Why? a little more authoritatively.
Allow me to chime in as I just spent a few hours going back and forth with different configuration trying to understand why I am not seeing the frontend tests listed in SQ.
We have the exact same setup as the OP: Maven multi-module with the frontend (Maven) module using the jest-sonar-reporter.
SQ ignoring the sonar.testExecutionReportPaths property defined at module level is IMO a violation of the principle of least astonishment (POLA) - particularly when scanning with Maven. With Maven a property defined at level N+1 (nearly) always replaces a property of the same name at level <=N.
What if you had two frontend modules frontend-A and frontend-B with both having their test-report.xml in different folders? Sure, you can put both paths comma-separated into sonar.testExecutionReportPaths. However, while scanning frontend-A SQ will complain about the missing 2nd path and while scanning frontend-B it will complain about the missing 1st path.
I have also lost countless hours with that issue. SonarScanner for .NET relies heavily on modules. It took me long enough to figure out how to configure an angular app sitting within a normal web project. To get everything working, I needed to add sonar properties to the .csproj file.
Naturally, I stopped seeing seeing JS unit test results. But I had no idea why.
If you really do not want to fix the issue, then please write at least an error message.
I’ll ping somebody who might be able to answer the Why? a little more authoritatively.