We are currently using the SonarQube community edition and are evaluating SonarCloud. One of the benefits that we were hoping to get by using SonarCloud is the analysis of pull requests and the integration into GitHub.
But we are struggling with the proper setup to analyse pull requests and update the status of the pull request in Github.
Our setup is as follows:
Our Git repositories are hosted on GitHub
Our development workflow is based on feature branches and pull requests
We build our application using Jenkins and Gradle
We are not using GitHub Actions to build the application (mainly because we have a huge codebase with a large number of tests that run for hours)
We use the ‘org.sonarqube’ plugin for gradle to report updates to SonarCloud
Updating SonarCloud after a regular build from our Master works without problems. But we were not able to properly set the things up to trigger an analysis after a pull request has been created and to update the pull request with the results from the analysis.
We played with GitHub Action workflows, but we did not get it to work.
Can we configure GitHub Actions to achieve that? Do we need to trigger a workflow that first builds the application via GitHub Actions and then communicates that information to SonarCloud?
Or do we need to notify Jenkins upon pull request creation to start a build from the branch and send the analysis information to SonarCloud, which will then somehow send an update to GitHub to decorate the pull request?
We would very much appreciate it if somebody could give us some guidance on how to set this up properly.
Thank you for your response. My question was more general about a recommended setup.
Our general setup is that our code is hosted on GitHub and we build our software with Gradle and Jenkins on a local server.
We use the SonarQube plugin to update Sonarcloud within our regular build process. This process works perfectly fine (very similar how it worked with the SonarQube community edition).
But now we would like to analyse pull requests on GitHub and decorate the pull requests with the information about new issues being introduced by the changes. And here the recommended setup is not clear to me.
The Sonarcloud documentation refers to a GitHub action and also mentions that it is including a scanner for gradle. When reading the documentation about the action, it is stated not to use the action when building the code with gradle. This is quite confusing.
Our current attempt uses a GitHub Actions workflow that builds the software including the gradle sonar task that sends the information to Sonarcloud. This is working ok, but I still have the feeling that it is not setup the way it should be:
We have a repository with approx. 30 projects that assemble our application. When I have a pull request with changes in one of these projects, the Sonarbot adds a comment for each of the 30 projects, which creates a lot of noise.
So my question is now, whether there is a better way to integrate Sonarcloud into our build infrastructure and/or if there is a way to only analyse and report changes that are introduced by a pull request.
And you have it set up in SonarCloud as 30 different projects…
But did you set it up on SonarCloud as a monorepo? If not, it may just be easiest to delete everything on the SonarCloud side and re-import. We’ve recently improved the UI for that, so it should be pretty easy. Of course, you do lose your project history that way.
Regarding Jenkins or GitHub Actions, there’s no need to switch. If you’re happy on Jenkins, you can certainly stay there; just make sure the job fires for PRs as well as main. The relevant values to mark it as a PR analysis should be picked up automatically from the envvars.