Must-share information (formatted with Markdown):
which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
how is SonarQube deployed: zip, Docker, Helm
I believe it is in an Azure App Service via Docker.
what are you trying to achieve
In C#, we had some classes with the
[System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverage] attribute. We removed the attribute and pushed an update. Now we’re making changes to that class, and adding unit tests, but that file is not listed in the coverage report after our pipelines run.
what have you tried so far to achieve this
Tried creating a fresh branch and re-implementing the changes in case the
git history somehow was incorrect.
Tried rebasing the branch onto
main to make sure the
git history was linear.
main branch lists that class with 0% code coverage now (expected). But the new pull request does not include that file in it’s coverage report at all.
Please let me know if I can clarify anything, thank you.
Edit: I added some more details in the first reply below.
I am attempting to accurately measure code coverage for a C# solution with a pipeline in an Azure DevOps repository. The solution has undergone changes, including removal of System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverage attribute from a class called MyClass, and addition of unit tests for it. However, the SonarQube Quality Gate report for the pull request on the feature/my-class branch is not including MyClass in its code coverage report, despite the attribute being removed and the main branch having been analyzed by SonarQube without the attribute. I want to ensure that the code coverage for MyClass is accurately reported in the pull request.
What I have tried so far:
- the first branch with our changes
feature/my-class (the git history may be confusing because this branch was created before
main branch was updated to remove the
ExcludeFromCodeCoverageAttribute - but there were no merge conflicts)
- I checked out a new branch from
feature/my-class and then did
git rebase main
- I checked out a new branch from
main, and then just copy/pasted all of the changes from
feature/my-class and pushed them in one commit
- The main branch, which no longer has the
ExcludeFromCodeCoverage attribute, shows 0% code coverage as expected due to lack of unit tests and incomplete implementation.
feature/my-class branch includes
MyClass implementation and corresponding unit tests with about 45% code coverage in local Visual Studio.
- Despite these efforts, the SonarQube Quality Gate report for the pull request on
feature/my-class branch does not include
MyClass in its code coverage analysis, behaving as if the
ExcludeFromCodeCoverage attribute is still present. This is inconsistent with the actual state of the code.
Note to the Sonar Community
I am facing an issue with SonarQube code coverage analysis in a C# solution with specific changes made to a class (
Despite removing the
System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverage attribute and adding unit tests, the code coverage report for the pull request on the
feature/my-class branch is not including
MyClass in its analysis.
main branch, without the attribute, displays 0% coverage as expected. I’ve attempted various solutions including rebasing and recreating branches, but the issue persists.
Any insights or guidance on resolving this discrepancy would be greatly appreciated. Thank you!
I’m starting to think the
ExcludeFromCodeCoverage has nothing to do with this, but our SQ cache might just need to be cleared.
Welcome to the community!
This is external to SonarQube and analysis. SonarQube simply reads the coverage reports you pass in. Files missing from your coverage report are a bit out of scope for us.
We don’t work from these attributes; only from your coverage reports and any coverage exclusions you’ve set on the SonarQube side.
This is unlikely. While we do cache information for issue detection for reuse in a PR context, we don’t cache coverage data. We just read the report you feed in, and we do it fresh each time.
Thank you for the great info.
I’m not sure what happened with this particular branch (its git history turned out to be messy and full of merges and rebases), but we were able to find a resolution (I was able to get accurate code coverage by creating a new branch and changing the name of the files to something slightly different.)
Thanks again for the thoughtful reply, it helps me understand where the issue might be in the future. (likely with how our coverage report is being generated).