My team has a hosted SonarQube server (Enterprise Edition) where we push PR analysis. The analysis is done using the Maven plugin by running the command mvn sonar:sonar. For this command, we also provide the path of the Jacoco aggregate report XML path to get coverage data. (The base branch has regular branch analysis, where we push the coverage data.)
In the SonarQube UI’s project settings, we add exclusions under analysis scope for some classes that we do not wish to track coverage for. This is usually done by means of patterns.
One of the patterns is **/src/main/java/**/*DAO.* but we notice that files under this pattern still are being tracked for coverage. For example, ABCModule/src/main/java/com/example/persistence/EntityDAO.java, which had new code added, was shown in ‘lines to cover’ in the new code section.
Note: We only add exclusions in the UI. There are no other properties specified during the analysis.
which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension) – SonarQube 9.1, Maven Scanner Plugin (not declared in POM but run with mvn sonar:sonar)
how is SonarQube deployed: – on cloud compute machine
what are you trying to achieve: – PR analysis where files matching pattern are excluded from coverage
what have you tried so far to achieve this – this used to be a working setup. Unsure of what changed.
Thanks, Colin. I will work with my org on the same. However, this will not be a quick task and we have PRs that cannot be analysed properly due to this issue. Furthermore, this used to work properly and I cannot fathom what could have changed to cause this issue to crop up all of a sudden. Is this a known issue with the current version? Will upgrade fix the issue?
I would suggest checking the analysis logs to understand what analysis parameters are being taken into consideration.
[**INFO**] Project configuration:
[**INFO**] Excluded sources for coverage: **/*.java
You mentioned that the **/src/main/java/**/*DAO.* is set in the UI… if a developer, for example, added sonar.coverage.exclusions somewhere else (in the pom.xml, as an analysis parameter to mvn sonar:sonar), this would be overridden by the hierarchy of settings.