- ALM used: Bitbucket Cloud
- CI system used: Bitbucket Pipelines
- Scanner command used when applicable:
dotnet sonarscanner begin /d:sonar.verbose=true /k:"${SONAR_PROJECT_KEY}" /d:"sonar.token=${SONAR_TOKEN}" /o:"${SONAR_ORGANIZATION}" /v:"${BITBUCKET_COMMIT}" /d:"sonar.host.url=https://sonarcloud.io" /d:sonar.cs.opencover.reportsPaths="${BITBUCKET_CLONE_DIR}/**/coverage.opencover.xml"dotnet builddotnet sonarscanner end /d:"sonar.token=${SONAR_TOKEN}"
- Languages of the repository: C# (.NET Core 8)
- Only if the SonarCloud project is public, the URL: project is private
- And if you need help with pull request decoration, then the URL to the PR too: code is private
- Error observed: This used to work, revisiting consulting project after some years, and PRs are flagged with issues on lines that are unchanged, and with 0% code coverage when there is coverage. Similar projects (different repos) with similar pipelines do not have this problem.
- Steps to reproduce: Open a PR that changes existing code, including test coverage. Test coverage is reported as 0%, and issues in the same code file but on unchanged lines are reported.
- Potential workaround: none
Hi,
Welcome to the community!
This is likely about your checkout.
Please make sure the prerequisites are in place.
HTH,
Ann
Could you be more specific please - especially with regards to the pre-requisite implications with Bitbucket Pipelines?
Again, we use a similar setup across dozens of repositories, with similar Bitbucket Pipelines configuration. We only see this issue with a single repository.
Bitbucket Pipelines does the checkout here. And we are already ensuring that a shallow clone is not used.
clone:
# SonarCloud scanner needs the full history to assign issues properly
depth: full
Hi,
My speculation here is that the necessary history lives in the workspaces of the build agents for these other repos, but got cleaned out (or not built yet) for this one specific repo.
Great! And that’s not the only requirement. Per the docs I linked above, you also need to make sure (among other things):
- The branch being targeted by the pull request is fetched and present in the local repository.
HTH,
Ann
So I’ve tried adding the following to the pipeline YAML:
# Trying suggestions from https://community.sonarsource.com/t/120994
- git fetch origin develop
- git branch develop FETCH_HEAD
- git branch
- git rev-parse develop
- git rev-parse HEAD
And confirmed that both the source and target branches are fetched locally, and their commit hashes match expected values.
+ git branch
develop
* task/sonarcloud-false-positives
The results are the same.
Hi,
Could we have a screenshot, redacted as necessary, of one of these issues?
Thx,
Ann
Not publicly, no. Unfortunately this is getting into confidential customer information. What details are you looking for from a screenshot?
The issues are issues that do existing the file modified, but the issues exist on lines of code that were not modified in the PR.
Hi,
I was looking for an indication of the rule language and ID, plus I wanted to see the new markings (or not) in the code.
Has the PR’s branch been rebased?
Ann
Here’s an example. Unfortunately I can’t share the associated code, but it is code that is not changed in the PR (though other lines in the file are changed).
And the PR has not been rebased.
Hi,
This issue isn’t coming from us. That’s why the key is listed as external_roslyn:CA1510. Now, it used to be that PR analysis analyzed everything and then filtered the results to just what was reported on changed lines. But for a while now, we’ve narrowed analysis to only what’s changed, and reported everything. So you’ve got extra, Roslyn analyzers running during the build, and their reports are being picked up (as expected) by analysis.
If you want to suppress those reports, check out the docs.
HTH,
Ann
That was just one example. There are plenty of standard Sonar issues being flagged too. This is not specific to the Roslyn analyzers. And, even if it were, Sonar is the one flagging lines that weren’t modified. And again, we have these same analyzers on other repos without this issue.
An example issue that is also flagged for a line not modified in the PR is:
Literal boolean values should not be used in assertions csharpsquid:S2701
This also doesn’t address the 0% code coverage.
Hi,
I can only work with what you give me.
Cool. How about a screenshot? Feel free to black out the code. I want to see the issue and the highlights & marginal markers.
We try to keep it to one topic per thread. Otherwise it can get messy, fast.
Ann
Help me out here. I am a paid customer. I’ve been using SonarSource for 9 years and SonarCloud for 4 years. We use SonarCloud to analyze 40 different repositories. Nearly all are structured the same, using similar Bitbucket Pipelines setups and SonarCloud configurations. We only have this issue on a single repository.
I can easily reproduce this by checking out a new branch and making a handful of small refactoring changes. The resulting PR is marked with 46 issues and 0% code coverage, even though the changes are demonstrably covered by tests.
Example issues are:
- csharpsquid:S2701
- csharpsquid:S2629
- csharpsquid:S6605
And many more. These are all on lines of code that were not changed whatsoever in the PR.
How do I get to the next level support? I’ve seen other tickets where folks are tagged in so that information can be shared in private. I am very limited in what I can share on a public forum.
Here is a screenshot of the issue flagged on lines of code that were not changed.
Here is a screenshot showing the lines of code that were actually changed, with no issues flagged, and with supposedly no code coverage.
Here are the same changed lined in an IDE showing code coverage exists.
Something else odd I’ve noticed that may be correlated to this issue. If I look at the Branches page in SonarCloud, it indicates the long lived branches haven’t been updated in 2 years, which is not the case. These have been updated, and scanned w/ SonarCloud, in the past few days.
SonarCloud:
Bitbucket:
Hi,
It’s really unfortunate that I can’t tell in this screenshot whether or not there’s a “new” highlight over the code.
Ditto.
We are not dealing with coverage in this thread.
Can you please share your full pipeline, redacted as necessary.
That’s certainly not helping. But you did say
Perhaps you can double-check those analysis logs and see where the final URL points?
Ann