PR decoration not reading new lines of PR

So I’m new on my company, and I’m trying to integrate SonarCloud inside our CI / CD pipelines and our ALM GitHub. When I’m checking the repository, I see files like .sonarcloud.properties and sonar-project.properties already there, which means that someone tried some time ago to integrate Sonar into our code. I do see hardcoded the value sonar.projectVersion=3.5.0.2 on both sonar files.

While I’m implementing my custom script called pr_build.yaml inside .github/workflows/ folder, I do see the PR decoration reflected on my new PR, but somehow the analysis doesn’t check the new lines that I’m adding. Instead, it checks some lines that were added between today and last month (oldest line is from Dec 4th, 2022).

This is my pr_build.yaml file:

name: Pull Request
on:
  pull_request:
    types: [ opened ]
jobs:
  sonarcloud:
    name: PR Decoration
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: SonarCloud scan
        uses: SonarSource/sonarcloud-github-action@master
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}  # Needed to get PR information, if any
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
        with:
          args: >
            -Dsonar.pullrequest.key=${{ github.event.pull_request.number }} 
            -Dsonar.pullrequest.branch=${{ github.event.pull_request.head.ref }} 
            -Dsonar.pullrequest.base=${{ github.event.pull_request.base.ref }} 
            -Dsonar.pullrequest.provider=GitHub

I do see reflected the following parameters on the github workflow execution:

Dsonar.pullrequest.key=1657 -Dsonar.pullrequest.branch=ENG-1002-Implement_automated_backend_testing_in_SonarQube -Dsonar.pullrequest.base=develop -Dsonar.pullrequest.provider=GitHub

Here are my sonar-project.properties:

sonar.projectKey=trip_ninja_api
sonar.organization=trip-ninja-inc-1
sonar.python.version=3.8
sonar.scm.revision=git
sonar.qualitygate.wait=true

.sonarcloud.properties:

# Path to sources
sonar.sources=.
sonar.python.version=3.8
sonar.scm.revision=git

I have a separate build.yaml for my complete analysis through AWS CodePipeline:

name: Build
on:
  push:
    branches:
      - develop
jobs:
  sonarcloud:
    name: SonarCloud
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0  # Shallow clones should be disabled for a better relevancy of analysis
      - name: SonarCloud Scan
        uses: SonarSource/sonarcloud-github-action@master
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}  # Needed to get PR information, if any
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

It’s important to remark that all these files are on a branch which I cut off from develop to work on the implementation. On develop branch, there’s no .github/workflows folder nor build scripts, and this is what sonar properties contain:

sonar-project.properties

sonar.organization=trip-ninja-inc
sonar.projectKey=trip-ninja-inc_trip_ninja_api
sonar.host.url=https://sonarcloud.io
sonar.login=XXXXX
sonar.sources=.
sonar.projectVersion=3.7.0

.sonarcloud.properties:

# Path to sources
sonar.sources=.
sonar.projectVersion=3.5.0.2

The analysis of complete code works fine inside our CI / CD pipeline in AWS CodePipeline, but while trying to scan only new code it’s when I’m facing issues. My main branch is being set as “develop”

  • ALM used: GitHub
  • CI system used: AWS CodePipeline
  • Scanner command used when applicable (private details masked)
  • Languages of the repository: Python

I even tried to setup a New Code category to check only new lines that are 1 day old (from yesterday), and after executing a complete analysis and then creating a PR is still not working.

I’m wondering if this is related to the hardcoded sonar.projectVersion that it’s on develop branch.

Hi,

You’ve got two different pipelines that act differently. Let’s look at how the pipelines are different:

You’re getting the correct behavior on your “complete analysis” because it has full SCM data available. Your PR analysis needs that data too. Otherwise it can’t tell which code is “new” and which isn’t - as you’ve seen.

 
HTH,
Ann

Hi Ann,

Thank you so much for your reply.

Are you telling me that I need to add fetch-depth:0 parameter on the PR decoration build file in order to detect which code is new and which code is not?

I’ve tried that and I’m still getting the old code that I don’t need to be analyzed in the PR decoration.

Is there any other advise that you can give me? I’m still stuck with this issue.

Thanks in advanced.
Christian.

Hi Christian,

Yes, you should make sure you’re doing a full fetch.

And if you’re still having issues, take a close look at the end of the analysis log, where SCM data retrieval happens. And/or feel free to share the log here.

 
Ann

logs.txt (14.5 KB)

Hi Ann,

please find attached the logs from “SonarCloud Scan” step. I didn’t find anything relevant.

Let me know if I need to check ther step of the workflow.

Thanks.
Christian

Hi Ann,

Is it possible that somehow an automatic analysis run on the first time in GitHub and this is why I’m getting previous commits? I found this on Sonar Documentation:

Existing pull requests on first automatic analysis

When a project is first imported into SonarCloud and analyzed by automatic analysis the first analysis behaves differently from subsequent analyses. On the first analysis not only will the main branch be analyzed, but, also the most recently active pull requests, up to a maximum of five. The main branch and pull request results will appear on the project overview, as usual. Subsequent analyses will occur normally, on pushes to the main branch and on pushes to pull request branches.

Thanks.
Christian.

Hi,

Yes, that’s entirely possible. The docs on automatic analysis include instructions on disabling it in case you want to do that.

 
Ann

Hi Ann!

Great news! Thanks for the documentation you shared, I found that the configuration that was adding more lines into the PR Decoration was inside of Administration → General → Sensor Cache. That checkbox was enabled and was retaining information (I guess) from older commits.

We can mark this issue as resolved.
Again, thank you so much for the quick response Ann

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