Backport PRs scans detect too many new lines

SonarCloud
1

KubeVirt · GitHub is using SonarCloud for multiple years to run CI on new PRs.
Recently, at least since July 23rd, some backport PRs failing SonarCloud CI, because unmodified lines are detected as relevant.
For example [release-v0.19] Fix runbook_url test by kubevirt-bot · Pull Request #1013 · kubevirt/ssp-operator · GitHub , which is a modification of two lines, is detected by SonarCloud as 13k new lines in SonarCloud .
Is this a config issue on kubevirt side?

1 Like
4

Hey @dominikholler

This probably relates to some changes made to the analysis of “external” (forked) PRs.

I’ll make sure the team sees this, but both our experts are on holiday (August in France…), so I’m not sure when it will get looked at.

At least, I see that most of your PRs are passing and behaving appropriately, so I hope the inconvenience isn’t too great. Thanks for your patience.

1 Like
6

Hi @dominikholler

Just to confirm: are you using Automatic Analysis, or do you trigger the analysis with your own CI?

I tried to reproduce your issue:

  • create a fork of your repo
  • create another fork
  • create a branch from the release-v0.19 branch and introduce an issue
  • submit this as a pull request upstream, targeting the release-v0.19 branch

Everything is working fine so far.

Is your bot doing some extra steps?

7

Hi , thanks for having a look.
I am not aware that we run sonar cloud on our own, we just enabled the most simple path, which might be Automatic Analysis.
I also do not see the issue happening anymore.
We also disabled sonarcloud because of this issue in https://sonarcloud.io/project/pull_requests_list?id=kubevirt_kubevirt , which is more complex. Let me check if we can enable it again.

8

I am unsure if I understand the sonarcloud analysis of

in
https://sonarcloud.io/summary/new_code?id=kubevirt_ssp-operator&pullRequest=1058
Does sonarcloud detect 13k new lines?

9

Hi @dominikholler ,

We deployed last Monday a change in the way automatic analysis checks out the code of a PR. Before it was analyzing the refs/remote/pull/X/merge Git reference, which contains the result of the merge of your PR head branch with the target branch. We faced many issues with this approach, for example when there are merge conflicts, and I wonder if your issue is not another symptom.
Anyway, we are now fetching from refs/remote/pull/X/head, like many CIs, so I am confident it should produce more reliable results.
May I ask you to retry automatic analysis, and let us know how it goes?

Thanks