Languages of the repository: Python, Javascript, Shell
Description
Project last Analysis at Sonar:
Project commit list: (note that non of the hashes are the same as the sonar one)
After following the link those are the commits hashes that the link points out:
Message at Github after following the link of the Last Analysis at Sonar: This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Steps to reproduce:
With the repository with automatic analysis create a new commit.
The commit referenced by the Last Analysis is different from the last commit of the branch.
Behavior before 2024-07-22
The hash of the commit at Github match the referenced in the Last Analysis
We have an integration that checks if the analysis is finished by comparing the hash of the last commit with the hash returned in the SonarCloud API (https://sonarcloud.io/api/project_pull_requests/list). Until July 22nd, this integration was working perfectly.
The problem started to occur only for projects that have automatic analysis enabled. That’s why I believe it may be related to the new feature launched on the 22nd.
We have indeed changed Autoscan checkout behavior on pull requests. We were previously checking out the “source” branch of the PR (which in the case of an external PR, could be located in another repository).
Now, we are checking out the ref that corresponds to the merge of the PR branch with the base branch. This is normally what GitHub Actions and most CIs are doing, and this gives the most accurate results.
But that is true that the last commit id is misleading, as it corresponds to the merge commit made by GitHub when creating the refs/pull/<id>/merge. This is something we can try to fix.
Out of curiosity, what is the behavior for your projects that are analyzed by GithHub Actions? Do you observe the same commit mismatch? Or maybe you have configured your workflow to checkout the PR head?
We see the same behavior. I think it is correct to run the actual analysis on the merge commit but the status check should be reported to the last commit of the PR and this is probably also the commit that should be reported as checked.
Indeed, we use the checkout as default, at the PR merge commit, but the Workflow that we use to integrate Sonar and some other requirements for our internal Quality Gates uses the github.event.pull_request.head.sha as the reference to check if the Last Analysis refers to the Last commit of the PR.
For now we can check both the PR merge commit and the HEAD of the PR.
We just tried with sonar.scm.revision=${{github.event.pull_request.head.sha}} and that seems to fix it for us. Now the commit in sonar is the same as the commit in the PR.
Not sure yet if this does have other implications.
Thanks for confirming that this sounds like the right direction.
I have created a ticket to do the same in the SonarCloud automatic analysis: override sonar.scm.revision to be github.event.pull_request.head.sha from the GitHub event.
For your information, the update we discussed has been deployed on SonarCloud today: the automatic analysis will automatically set sonar.scm.revision to the github.event.pull_request.head.sha value. That should make PR analysis more user-friendly.
