Sonarcloud considers main branch changes as "new code" in the PRs

SonarQube Cloud
1

Hey folks, we are using sonarcloud for sec vul scans and keeping our code quality high. We use https://github.com/SonarSource/sonarcloud-github-action but whenever we create new PR with very small change, it also considers code merged in main branch to be “new code” and fails. Has anyone ever bumped into this issue?

Meaning

  • Let’s say author A changed 10 files and merged to main branch with little less coverage than required in master.
  • Author B creates a PR with only 1 liner change, sonarcloud would fail pointing that “10 (from main)+1=11” files require tests for it to pass while it should only care about what’s changed in the PR.
2

Hey there.

Thanks for reaching out to us on this.

What does your GitHub Actions YAML file look like? Please share it entirely.

3

Hi, here is the action

https://pastecode.io/s/sbc2erue

4

Hey there.

  - uses: actions/checkout@v2
  - name: Get changed files
    id: changed-files
    uses: tj-actions/changed-files@v11.5

This is really going to mess SonarCloud up – as it expects to have the full code-base and references to the target branch.

This is the checkout you want:

    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0  # Shallow clones should be disabled for a better relevancy of analysis
5

hey @Colin thanks for reply.

I wonder why would this mess SonarCloud up? The reason why we are doing it is because we only want to create report for files changed in the PR and not all codebase. If we do not do that Sonarcloud runs all the jest test which takes really really long time. Also shouldn’t fetch-depth:1 only pull one commit and then the surface area for sonarcloud be small (just trying to understand how sonarcloud works, I know it should not be 1)

6

SonarCloud runs a full analysis even when only a few files have changed, and filters the results down to the changed files/lines at the end. We’re hoping to improve this soon so that unchanged files are skipped when possible. At the same time – it’s probably a good practice to run all of your tests for a codebase to make sure changes in one place didn’t affect other parts of your code.