Sonarcloud check for Github never succeeds

[dcacenabes]

• Sonarcloud, Jenkins (Triggers the build), Github
• error observed
  Sonarcloud successfully comments in the PR, and the quality gate passes, but the github check “SonarCloud Code Analysis” remains as “Expected - Waiting to be reported”
  
  
• steps to reproduce: It happens randomly, and not for all PRs
• potential workaround: We don’t have one
  This is very bad for us as it is blocking our PRs from getting merged.

I found some related issues but they were flagged as resolved already:
https://community.sonarsource.com/t/sonarcloud-code-analysis-expected-onoging-issues/28154/66

[Marcin_Majewski]

Hello,

Thanks for reaching out. In order to help with this problem, I would like to ask you, if it is possible for you to provide me with the background task id which resulted in the check that was not delivered? You can find this in the “Administration” -> “Background Tasks”.

Best,
Marcin

[dcacenabes]

Hi @Marcin_Majewski,

Thanks for your quick reply. This one failed to submit the check:
AXZMcsOGkbXLIe1RIk9d

This one too:
AXZMbrqrCSEsAHsHwEj2

This one, for instance, succeeded:
AXZMcDVJCSEsAHsHwEkg

[Marcin_Majewski]

Hi,

Thanks for the information. The messages are appearing in the PRs as they are created for the specific PR (no information about revision is needed), whereas the GitHub Checks are created for a specific commit. I looked into the logs and my suspicious is that the analysis is run before the commit is present on GitHub. Is that may be the case? (in that case, re-analysis should make check appear on the PR)

Best,
Marcin

[dcacenabes]

@Marcin_Majewski

Thanks for the information. The messages are appearing in the PRs as they are created for the specific PR (no information about revision is needed), whereas the GitHub Checks are created for a specific commit. I looked into the logs and my suspicious is that the analysis is run before the commit is present on GitHub. Is that may be the case? (in that case, re-analysis should make check appear on the PR)

Best,
Marcin

Hi @Marcin_Majewski,

In Jenkins we’re creating a virtual merge between the source and target branches for the PR and run Sonar on that merge. That commit will never show up in the PR because it will never be pushed. I think this is compatible with what you’re saying. I would guess that for the cases that it is working is because there are no other commits in the target branch and then the virtual merge is just a fast forward, so the commit actually exists.

Is there any way for us to pass in a parameter to sonar to specify the hash of the commit manually?

[Marcin_Majewski]

Hi @dcacenabes,

In that case, specifying sonar.scm.revision property to the commit hash you want to decorate should do the trick.

Best,
Marcin

[dcacenabes]

@Marcin_Majewski a follow up question: is there any way for me to figure out which commit was associated to the background task?

[Marcin_Majewski]

@Marcin_Majewski a follow up question: is there any way for me to figure out which commit was associated to the background task?

I am afraid this is not possible. If you want to verify that that indeed the commit hash used to decorate was wrong I can send you the sha in the private message (if you provide me with specific project key in the private message).

Best,
Marcin

[dcacenabes]

@Marcin_Majewski

I am afraid this is not possible. If you want to verify that that indeed the commit hash used to decorate was wrong I can send you the sha in the private message (if you provide me with specific project key in the private message).

Best,
Marcin

No needed, I could look into our Jenkins logs and confirmed that we were passing the temporary merge commit SHA. Passing the “sonar.scm.revision” parameter did the trick! Thanks a lot for your help @Marcin_Majewski