We’re using SonarCloud with GitHub on private repositories.
The SonarCloud projects are linked to GitHub repositories and we’re successfully getting PR decorated, and most of the time, we’re getting the SonarCloud Code Analysis commit status check from SonarCloud. The problem is that randomly, on some PRs, the commit status check isn’t reported.
For example PR #12285 in repo AlayaCare/phpapp was successfully decorated but did not receive a status check. We can see the background task AX8nrmwkbrHHZFBAdlzh shows as SUCCESS.
For other PRs in this repository, when this happens, we rerun the job and in general it fixes the problem, but this is not sustainable. We would like to make this status check Required to enforce the Quality Gate but we cannot ask the developers to constantly rerun jobs.
Is there an open issue for this on SonarCloud side? Something we can do to mitigate/workaround this problem which seems to be between SonarCloud and GitHub?
Jenkins + Pull Requests + Sporadically working decoration? I think I can tell you what’s going on.
When SonarCloud identifies that the scan is being run in Jenkins, it uses the GIT_COMMIT environment variable to populate sonar.scm.revision – which is ultimately used during Pull Request Decoration to decorate a particular commit on GitHub.
The problem is that this GIT_COMMIT does not always exist on GitHub. The default checkout strategy used by Jenkins is to merge the target branch onto the P/R branch. If both branches have diverged, this will create a merge commit that only exists locally. This causes somewhat sporadic behavior where sometimes the SCM revision exists in GitHub (thus PR Decoration works), and sometimes it doesn’t.
We found a solution for SonarQube users (and implemented it with SONAR-11853, where you’ll find a similar description of the problem as what I wrote above). This change was, for whatever reason, not implemented in SonarCloud.
I’m following up internally to see if we plan to introduce better auto-detection of this parameter for Jenkins+SonarCloud setups. In the meantime, you might try generating the right value yourself and passing it to sonar.scm.revision. A git command in your pipeline to generate the right value might look something like this:
