GitHub Pull Request decoration fails due to missing commit

Continuing the discussion from Github pull request decoration failing, missing commit SHA:

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)

    • SonarQube 10.6.0.92116
    • sonarsource/sonarqube-github-c-cpp@v1
    • sonar-scanner-5.0.1.3006-linux
  • how is SonarQube deployed: zip, Docker, Helm
    zip

  • what are you trying to achieve
    I was updating my GitHub Actions workflows to use sonarsource/sonarqube-github-c-cpp@v1 for scanning C/C++ projects.

  • what have you tried so far to achieve this
    I have configured a workflow that is triggered on pull request events (opened, synchronize and reopened). Most of the times it works fine, but sometimes it fails due to a “missing” commit.
    Initially, I got a warning in SonarQube when using actions/checkout@v4 as described in the docs. By default, the checkout action uses GITHUB_SHA, which according to the GitHub Docs may not be the commit ID for the last commit to the head branch.
    To address this, I made the checkout action to use github.event.pull_request.head.sha, which should be the commit ID for the most recent commit to the head branch of the pull request. Although the GitHub actions workflow seems to consistently check out the correct commit, the scanner seems to still be using the GITHUB_SHA commit, which sometimes isn’t the correct commit.

Do you have any suggestions on how to resolve this issue?

Hey there.

Can you try setting sonar.scm.revision explicitly to github.event.pull_request.head.sha? This would look something like this:

-Dsonar.scm.revision= ${{ github.event.pull_request.head.sha }}

1 Like

I did some tests and it seems to be working, but this is a bit tricky to reproduce because I cannot be sure that the GITHUB_SHA was different github.event.pull_request.head.sha each time I did the test.

However, since it now seems like the scanner is always using github.event.pull_request.head.sha, I think it’s fixed.

Thanks a lot!

Hey @pcosta

We did some investigation and this should be the default behavior, so we created SONAR-22640.

Thanks a lot!

1 Like

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