Republish short-lived branch analysis as check when PR is opened

SonarCloud
1

Our organization is using short-lived feature branches built on Jenkins CI and analyzed with SonarCloud. We can see the results of the analysis in SonarCloud.

Now, if we open a pull request, it will inherit the Jenkins CI commit status, but not the Sonar Cloud analysis. It also won’t include any SonarCloud check, even though the commit has been analyzed when the branch was built.

Is there any way to make SonarCloud update the commit status and add the check when the pull request is opened?

The only workaround we’ve found is to trigger the CI again with a webhook when PRs are created. If there was a way to reuse the already existing analysis we would save a lot of time in our workflow.

1 Like
2

We are currently working to add proper support for branches and PR in the scanner for Jenkins (SONAR-11853), I guess (hope!) this should help solve your problem.

3

I don’t think this would solve my case. We’re using the Maven Scanner, Gradle Scanner and the SonarScanner directly in our pipelines. I think the problem is that SonarCloud posts results differently depending on whether it is a PR or a short-lived branch.

What I’m looking for is a way to avoid triggering a build altogether only to get SonarCloud to post a check status to GitHub. The ideal solution for me would be this:

  1. The CI builds short-lived branches and forked PRs and runs analysis against SonarCloud
  2. When a PR for a short-lived branch is opened, SonarCloud would receive a webhook event from GitHub and republish the already performed analysis as a status check. The event include all the details about the pull request that SonarCloud would need. I’m not sure if SonarCloud tracks the commit SHA the analysis ran at?

The webhook solution is what we’re doing now with our Jenkins, with the major downside that we need to rerun the complete build to correctly track issues and coverage.

If I use the GitHub API I can see that no checks are posted to the short-lived branches, only on PRs. I’m not sure if this is a limitation of the GitHub API or something that could be added for all analysis?

7

OK, thanks Samuel for the detailed description. This is something we might improve later, but for which we currently have no plan. Still, we keep this idea in our radar.
Thanks!