We have an odd problem with newly setup SonarCloud projects used to monitor our Devops PR builds.
Running the build definition manuall for our .net core C# code in the Devops git repo goes great. We can see the results in Sonarcloud.
When the builds run from a branch policy kicked off from a PR, the SonarCloud tasks seem to run fine but no code coverage data is posted to SonarCloud for that build. I can see the activity under the pull requests, but there is no useful information in there.
I reviewed the steps/configurations in this lab , and everything looks correct.
Has anyone else experienced this? Do we need to assign a user to the build agent or something?
We are having the same problem since a week or two. At first it was just me having it configured wrong, but the logging shows that when it falls back to loading from the _temp folder on the agent it neither indicates it has found code coverage files nor that it could not find code coverage files.
I just don’t understand why there’s a difference between running it manually and having the PR kick of the build.
Hi @RobP and @Vossekop,
The difference is that we populate some extra properties (the Pull Request id for example) to differentiate it from a branch analysis.
Could you please share both working coverage “Run Code Analysis task” and the one at 0%, with debug logs enabled, so then we can troubleshoot ? I can send you a PM to share it privately if you want.
Yes, PM sounds good. I’ll figure out how to run it in debug mode and send you the logs for both sometime today. thx
So I think I figured this out. It’s probably PEBCAK. Our CI/CD had a branch policy but we didn’t have the Continuous Deployment trigger turned on in the build definition, so it wasn’t doing a build once it merged into the target (dev) branch. The sonarcloud project is set to “dev” for the branch. Therefore it correctly didn’t count those stats into a legit analysis run because the branch was the temporary one used during a PR build policy gated build.
Now that we’ve got those CI/CD settings corrected, things seem to be recording fine.