Must-share information (formatted with Markdown):
- which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
SonarQube 7.6
MSBuild/dotnet scanner 4.6.0
- what are you trying to achieve
Accurate test coverage delta between short-lived branch compared to target branch
- what have you tried so far to achieve this
Analysis parameters look like:
/d:sonar.cs.opencover.reportsPaths="$coveragefiles" \
/d:sonar.coverage.exclusions="**Tests*.cs" \
/d:sonar.branch.name="${branch}" \
/d:sonar.branch.target="develop" \
When looking at code coverage in sonarqube after the first time a scan is performed of the short-lived branch, it usually shows what looks like accurate numbers. Though we’ve noticed that isn’t always the case (I’m not reporting this as a bug because it seems likely we’re doing something incorrectly, just not sure what).
If a branch author subsequently pushes commits on the same short-lived branch, triggering another scan, then test coverage in sonarqube looks like it is only comparing changes between the previous commit and the current commit, instead of between sonar.branch.name and sonar.branch.target.
I haven’t been able to find any other reports of similar behavior in the community, but figure others would almost certainly run into it. Hence the theory that we’re doing something wrong in the scanning process.
Right now, we run tests to generate coverage reports, then start the scan and build the solution with the opencover report paths ready.
Any ideas?