I have a mystifying situation with one project build that is somehow omitting the coverage for an entire package, which drops our coverage percentage well below our required quality gate. This is the build for the “master” branch.
I then created a pull request with essentially no changes (removed some commented code in the POM), which uses the same Jenkinsfile (but omits some steps for a pull request build), but runs the SonarQube scan on all the same code. Comparing the scan results between the two, the PR build had the expected coverage percentage, but the master build had the lower number. I confirmed in the detailed measurements that the PR build was not omitting the coverage for that one package.
Note that in the master build, it had been setting “sonar.cpd.exclusions” to exclude the particular package that is missing coverage. Logically, that shouldn’t affect coverage. In the PR build, I tried toggling that exclusion off and back on. Toggling it off raised the detected duplications, but had no effect on the coverage. Toggling it back on again restored the duplications percentage to be the same as the master build, still with no impact on the coverage percentage.
I did a detailed comparison of the Jenkins console log for the two builds. I thought I would see a difference in the “Java {Main,Test} Files AST scan”, but there was no difference. They had the same number of main and test files to scan.
The only other curious difference I saw was that the master build had MORE unit tests detected, but they were actually not unit tests run by Surefire, they were special “pact” tests that run in a different part of the build. The PR build doesn’t run those “pact” tests, so that partially explains why they weren’t in the unit tests list for the PR build. I don’t know why SonarQube thinks these are unit tests, but I also don’t think it’s likely that their presence could LOWER the resulting coverage.