Quality gate failing for issues in unmodified lines of GitHub PRs

SonarQube Cloud
, ,
1

Hi,

We use SonarQube Cloud. For a while we’ve seen Sonar decorate unmodified lines of PRs with violations in GitHub. We’ve been ignoring it, but we noticed today some of the old findings are blocking the merge (security findings, bugs).

These are false positives, or not possible in our environment. We can mark them as such, but something seems to be not working as expected, as the documentation and forum posts indicate only modified lines are considered for PR decoration (and presumably for the quality gate).

We’re using a monorepo. We do a full checkout for our Sonar jobs so it can see history. We do a regular scan of our main branch to keep the main branch analysis up to date.

I can see Sonar knows the code is not new, because it’s not shown in blue in the Sonar UI, and not counted as uncovered new code in the PR. But it’s decorating the PR with the finding, and marking the quality gate as failed until we mark it as a false positive. Is there anything else I should check?

  • GitHub
  • CircleCI
  • Gradle sonar plugin version 6.2.0.5505 (this is a bit old, can try upgrading)
    • We were on Maven until recently, but I think it had the same problem
  • Java

Sonar view:

image
image1494×866 86.9 KB

GitHub view:

image
image1709×687 50.5 KB

I can share URLs privately if needed.

Thanks,

Mike

2

Here’s another example, from a PR that changed copyright headers across thousands of files. The PR summary shows “0 New Lines of Code”, because no code changed, only comments; but the quality gate status is Failed, which blocks us from merging. The issues are all historical, introduced long before the PR.

image
image2930×1594 246 KB

3

Hey @ms1111, it looks like a bug, but there’s something I would like to check before raising it further: do you have any recent analyses/have you every analyzed both the PR branch and the develop branch? I mean, a branch analysis on those branches, not a PR analysis. If so, could you check if develop also shows these “unrelated” issues that are being found on the PR? Could you check if there’s anything anomalous in develop, like for example not any issues found at all in the branch, or way less than expected?

5

Hi Andrés,

Thanks for your reply. Taking a look:

  • We do have a branch analysis on the default develop branch. It’s from 14 days ago (normally we run it every 7 days - I will look into this)
  • The default branch appears to have all the expected issues
  • We don’t run a separate branch analysis but we pass both the branch and the PR to Sonar. Like this:
CIRCLE_PR_NUMBER=$(cut -d/ -f7 <<< "$CIRCLE_PULL_REQUEST")

./gradlew sonar -Dsonar.host.url=https://sonarcloud.io \
    -Dsonar.organization=xxx \
    -Dsonar.projectName=xxx -Dsonar.projectKey=xxx \
    -Dsonar.cpd.exclusions=** \
    -Dsonar.branch.name=${CIRCLE_BRANCH} \
    -Dsonar.pullrequest.branch=${CIRCLE_BRANCH} \
    -Dsonar.pullrequest.key=${CIRCLE_PR_NUMBER} \
    -Dsonar.pullrequest.base=develop \
    -Dsonar.pullrequest.provider=github \
    -Dsonar.pullrequest.github.repository=xxx/monorepo
    -Dsonar.token=...

I’ll try something here: We switched from Maven to Gradle in the last couple of weeks, so I’ll see if I can trigger a fresh develop branch analysis, in case that makes a difference. It’s supposed to run weekly, in any case.

Thanks,

Mike

6

OK, I’m guessing the migration from Maven to Gradle changed something about the identity of the files from Sonar’s perspective. (Same file paths, same module names, but now it’s Maven instead of Gradle.)

Forcing a fresh analysis of the branch has resolved the problems for pull requests: the quality gate passes now.

I believe all the things we’d previously dismissed as false positives on the main branch in the Maven days, are now showing up as open issues on the main branch. Maybe there’s a way I can dump the old resolutions with the API and resubmit with the new identity.