SonarQube not reporting to GitHub for Merge Queue event

Versions:

  • SonarQube v10.4.0.87286
  • Using SonarSource/sonarqube-scan-action@1b9d398800bf807ad36901b351fff52deba642d6 (GitHub Action)

SonarQube is reporting back to GitHub correctly, when in the context of a Pull Request. However, in the context of a Merge Queue event (merge_group in GitHub), it does not seem to report back a commit status to the commit SHA.

In the SonarCloud product, you can fix this by by running the tool with an additional property, -Dsonar.branch.name=merge-queue, and then configuring this fake branch name “merge-queue” as a “Short-lived Branch” in SonarCloud Admin panel. However, the SonarQube admin panel does not seem to have any such configuration setting that I can find.

Has anyone found a solution to this issue? We want to block merges to our main branch on the successful result of SonarQube, but we can’t do that if it does not report back a commit status on the commit SHA of a merge_group event in GitHub.


If it helps, I am attaching, not the logs of the scan on our side, but rather the “analysis result” output on the cloud/server side after it completes:

Sonarcloud (successfully sets a commit status):

{"task":{"id":"AY56usbfLOdq6J14ZPo4","type":"REPORT","componentId":"AYfs3_RIvOFgX8kD9gw2","componentKey":"xxx-swift","componentName":"xxx-swift","componentQualifier":"TRK","analysisId":"AY56ussE9OuGP7U_KOlm","status":"SUCCESS","submittedAt":"2024-03-26T13:27:24+0100","submitterLogin":"xxx","startedAt":"2024-03-26T13:27:25+0100","executedAt":"2024-03-26T13:27:28+0100","executionTimeMs":3060,"logs":false,"hasScannerContext":true,"organization":"xxx","branch":"merge-queue","branchType":"SHORT","warningCount":0,"warnings":[]}}

SonarQube (does not):

{"task":{"id":"ae4ed642-7310-43be-8605-8237d06b969c","type":"REPORT","componentId":"c5a89906-e9bd-49d1-8c85-f0579259da7d","componentKey":"xxx-swift","componentName":"xxx-swift","componentQualifier":"TRK","analysisId":"13e98dd8-f1ad-4fb4-8350-15b2a5e13b9d","status":"SUCCESS","submittedAt":"2024-03-26T12:27:16+0000","submitterLogin":"xxx","startedAt":"2024-03-26T12:27:17+0000","executedAt":"2024-03-26T12:29:25+0000","executionTimeMs":127976,"hasScannerContext":true,"branch":"merge-queue","branchType":"BRANCH","warningCount":2,"warnings":["Failed to report status to Devops platform: couldn\u0027t get the branch details. Contact your SonarQube administrator to check the server logs.","Failed to report status to Devops platform: couldn\u0027t get the branch details. Contact your SonarQube administrator to check the server logs."],"nodeName":"sonarqube-sonarqube-dce-app-6b6954cbf4-pvjcf","infoMessages":[]}}

Hi @elliot-nelson

Can you let us know your CI configuration to further investigate. Are you trying to push a check when scanning branch A and report it to branch B?

Thanks for the clarification.

Hi @Mathieu_Suen !

So, we have a very simple setup right now, out of the box Sonar scan for SonarQube in a Swift repository, here is an example of what we run for Swift:

      - name: SonarQube
        uses: SonarSource/sonarqube-scan-action@1b9d398800bf807ad36901b351fff52deba642d6
        env:
          SONAR_TOKEN: ${{ secrets.SONARQUBE_TOKEN }}
          SONAR_HOST_URL: https://<our URL>
        with:
          args: >
            -Dsonar.coverageReportPaths=${{ steps.coverage-reports.outputs.paths }}

The issue here is that this workflow is triggered by both “Pull Request” and “Merge Queue” events in GitHub.

For Pull Request events, everything works properly. But for Merge Queue events, there seems to be a lot of issues – each time it runs, for example, it takes >5 mins instead of the typical ~10 seconds (it takes the time of a new branch, rather than an incremental scan).

Also for Pull Requests, it seems like it intermittently gets confused by GitHub’s “hot merges” – it tries to report the SHA status back directly onto the commit SHA that is checked out, rather than the SHA that is actually on the pull request. This results in “failure to report status back to devops provider”. (I realize this second issue might be unrelated however.)