PR scan picking up unrelated, already reported code smells (CFamily)

SonarQube
1

10.2 enterprise, recently upgraded from 8.9
Scanner 5.0.1 from zip running in own docker container

My understanding is that PR scans should only report issues introduced with the PR, regardless of the project’s New Code Period.

I have a PR that introduces new sources to scan (though source files are not new) and they have some 7 code smells. However, the scan picks up an additional ~80 code smells coming from the already reported 400 code smells on the main branch. Main branch tracks new code by version, and the version dates from about 4 months (we’re still at the setup stage with SQ). We’re using Code Variants but not adding any new variants through this PR.

When I look at the log, I see the SCM Publisher analysing 15k (!) commits dating all the way back to 2014, which I found a bit odd. If I disable the SCM Sensor and run the scan again, it reports only the 7 code smells, as expected. But of course it’s missing the PR decoration so that’s not a solution.

The “merge base sha1” reported is from Aug 19, 2023, which I also can’t relate to anything.

If I look at the history of the last 4 months’ PR, I see that with time, “Duplications on x New Lines” just keeps increasing from 700 on the first PR 4 months ago, to 31k on the most recent. No way so many new lines were introduced by those PR, but possibly through the addition of scanned sources.

I did create a new project mirrored on the original one, but could not reproduce the problem.

I had to anonymize the log, hope it’s not too much.

Not too sure where to attack this from, any hints?

sonar-scanner-log.txt (54.8 KB)

2

Hi,

Welcome to the community, and thanks for including your log in your first post!

Yes, that’s right.

I suspect this is about what’s available in the environment.

Per the docs

Before analyzing your pull requests, make sure that:

  • The pull request source branch is checked out in the local repository.
  • The branch being targeted by the pull request is fetched and present in the local repository.
  • The analysis is being run on a local repository with valid repository metadata (e.g. the .git folders have not been removed). Avoid any attempt at previewing the merge or actions involving your main branch.
  • The code in the local repository matches the code in the remote repository (e.g once a PR is issued, no code is added to the local branch on the CI side before analysis).

 
Ann

3

Spot on. Your reply led me to figure out that a performance tweak I had in place caused the target branch to be outdated. I didn’t see it because my other builds use Jenkins’ BitBucket’s “Current PR revision” and not the “Merge PR to current target revision” strategy, so target branch state didn’t matter.

1 Like
4

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.