Sonar cloud has started logging issues in unchanged lines in github PRs

In the last week or so we’ve started to see sonar firing issues on unchanged lines of code in our github PRs. This happens only on files that were touched. I tried changing the project’s definition of new code from the default since-last-version to 7 days, which did not affect this behavior.

(This is a private repo so I can’t share the details.)

Sonar is triggered by a github action:

name: Sonarcloud (with coverage reporting)

on:
  workflow_call:
    inputs:
      COVERAGE_FILENAME:
        description: The name of the coverage file to download. Defaults to "code-coverage-report".
        type: string
        required: false
        default: "code-coverage-report"
      WORKING_DIRECTORY:
        description: Path to the directory/project the analysis should be conducted on.
        type: string
        required: false
        default: "."

jobs:
  sonarcloud:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          # Disabling shallow clone is recommended for improving relevancy of reporting
          fetch-depth: 0

      - name: Download code coverage results
        uses: actions/download-artifact@v4
        with:
          name: ${{inputs.COVERAGE_FILENAME}}
          path: bin

      - name: SonarCloud Scan
        uses: SonarSource/sonarqube-scan-action@v6
        with:
          projectBaseDir: ${{ inputs.WORKING_DIRECTORY }}
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

properties file (redacted):

sonar.projectKey=REDACTED
sonar.organization=REDACTED
sonar.projectName=REDACTED

sonar.language=go
sonar.sources=.

sonar.exclusions=**/cmd/**/main.go, **/testutils/**, **/integration_tests/**, **/synthetic.go, **/mock/*.go
sonar.tests=.
sonar.test.inclusions=**/*_test.go

sonar.go.tests.reportPaths=/home/runner/work/REDACTED/bin/coverage.out
sonar.go.coverage.reportPaths=/home/runner/work/REDACTED/bin/coverage.out

sonar.sourceEncoding=UTF-8

thanks!

Hi,

Welcome to the community!

Are you seeing the lines for those “extra” issues marked as new? Or are they new issues on old code. The latter are likely legitimate (if you disagree, please share the rule keys involved.) The former would be about your checkout and the SCM metadata available to analysis.

 
HTH,
Ann

Thanks Ann! The issues are legit, but are showing as new, causing my quality gate to fail, as seen in the example screen shot below. None of the 12 “new” issues are in functions changed by this PR. I expect the quality gate to pass with no new issues when all the issues found are on other code.

Hi,

So the issues weren’t present in the file before the PR. They were caused by the PR. It’s just that they’re not on lines changed by the PR?

This is how issue detection works for SonarQube Cloud.

You can Accept them to make the PR pass its quality gate (or you could fix them in code. :wink:)

 
HTH,
Ann

The issues were not caused by the PR – while the errors are legit, such as not checking an error return value in go, that’s totally localized to one line, and the offending line was present in the preexisting code.

Hi,

Okay, when’s the last time you analyzed the base branch? Is the issue present there?

 
Thx,
Ann

our CI system is not configured to run an analysis when a push happens to main - it appears a main branch analysis has never been run for this repo. is that causing sonar to get confused about what issues are new?

Hi,

Yes, that’s the problem. The PR anlaysis is reporting all issues that are “new” versus the base branch. So for this to work, you need to keep your base branch analysis up to date.

 
HTH,
Ann

1 Like

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