Code coverage file not recognized

[Niton (Nils Brugger)]

• ALM used : GitHub
• CI system used : GitHub Actions
• Scanner command used when applicable: ./gradlew sonarqube
• Languages of the repository: java
• Only if the SonarCloud project is public, the URL: https://sonarcloud.io/summary/new_code?id=nbrugger-tgm_java-spring-template&pullRequest=16
• Pull Request: feat: add qs workflow by nbrugger-tgm · Pull Request #16 · nbrugger-tgm/java-spring-template · GitHub
• Build System : gradle + sonarqube
• Coverage Tool: JaCoCo
• Additional Info : Multi-module build

Error observed

When my CI executes the :sonar task the output seems to find and process the JaCoCo XML file.
Link to the output: GH Workflow Log snippet

So while the file is uploaded (at least the log indicates it) the shown result is still : “No code coverage data”

Additional Information

• The only module that produces a coverage report is app
• The path of the report is altered (for jacoco and sonar) : (projectpath)/build/reports/jacoco/coverage.xml
• If you want to see the lines where jacoco and sonar is configured: here
• The file submodule.gradle is applied to each subproject

Steps to reproduce

• Create a fork ok GitHub - nbrugger-tgm/java-spring-template: A template to create high quality Spring apis using: Docker, Gradle, OAS(open api). Including github actions for quality ensurance, autogeneration and deployment
• Create a branch with name feat/somefeature on your fork
• fast forward or rebase the created branch onto my feat/qs-workflow branch
• Open a PR to my dev branch
  • Make sure to name the PR feat: test-sonar-issue
    (You will most likely need to wait for me to accept the wokflow run)

Following theese steps should result in the same behaviour

Thank you

[Niton (Nils Brugger)]

I think I figure out what’s wrong.

Since the only source code changes are unit test classes sonar ignores the test reports with the message “Set up codecoverage… heres the guide …” instead of “100%” which depending on the point of view makes sense, or not.

Maybe the message “No codecoverage required for this changes” would be a less confusing display message