Sonarcloud analysis for PR based approach

We are using sonarcloud for our public repositories and we follow PR based approach. We are using CircleCI as our CI tool.
Right now, I’m getting analysis when a PR is raised. I’m using sonar.pullrequest.key, sonar.pullrequest.branch, sonar.pullrequest.base parameters in the sonar command so that it giving PR based analysis.

Requirement: For each PR raised we need PR based analysis and also branch-based analysis to where that particular PR gets merged. How to achieve this using CircleCI?

Hello Harsha,

We recently added support for running analyses on CircleCI. We use the environment variables that CircleCI exposes to configure the parameters you mentioned, so you can drop those.

This sentence is not completely clear to me. What I understand is that you want to analyze the new code that is present in the pullrequest. What I do not understand is what you mean when you say

Does this mean that you want to get an overview of all the issues that exist in the target branch (the branch the pull request will be merged in)?

Thanks,
Tom

Thanks for the response @TomVanBraband, Yes exactly that’s the requirement.
Now, I’m passing parameters which is required for PR analysis in sonar command, which is analyzing and giving result only for the code change in that PR.
At the same time we need whole branch analysis for the PR which is getting merged to target branch. Hope I’m clear now.

Hi @harshavardhanc

We changed this behaviour a few weeks ago, it is now not necessary anymore to pass those parameters. PR analysis will be set up automatically when you run the sonar command without parameters in a CircleCI environment.

Usually the target branch of your PR will be a long-living branch on SonarCloud, and this branch will show all the issues it contains on SonarCloud. The PR will show all the issues that exist in the newly added/edited code. Would this cover your usecase?

To achieve this with CircleCI you would have to setup your build so that analysis gets triggered on every PR commit and on every commit on a regular branch. If analysis is triggered on a branch, and this branch
is the main branch or a long-living branch (see the docs), then it will show all the issues that exist in that branch. To set-up branch analysis you will also not have to pass any parameters to the sonar command.

In short just running the sonar-scanner command without any parameters on every commit should cover your described usecase.

Please let me know if this helps.
Tom

PS: we also have a CircleCI orb to simplify your config.yml

Thanks a ton! @TomVanBraband For the detailed explaination. Now we are getting both PR based analysis and once that is merged to the target branch we are getting whole branch analysis.

1 Like

Hi @TomVanBraband

As you mentioned, we tried it is actually working for some of the repositories and it is not working for some, it is failing by saying Parameter ‘sonar.pullrequest.branch’ is mandatory for a pull request analysis

Not sure, whether I’m doing something wrong. Below is the link of our circleci build which failed with that error.
https://app.circleci.com/jobs/github/project-sunbird/sunbird-analytics/639

Hi @harshavardhanc,

I suspect you might not have linked some of your SonarCloud projects to their corresponding repository on Github. We need to know the location of your repository on Github, since we use Githubs API to determine the sonar.pullrequest.branch parameter.

You can easily check if this is the case, do you have a small Github icon next to the SonarCloud project in the project overview for which the automatic configuration is not working?

Thanks for the quick response @TomVanBraband

Hope this is the icon you are talking about. Please let me know if it is the wrong one.

image

Hi @harshavardhanc,

I did some digging and I found the root cause. CircleCI does not expose environment variables by default when it runs forked PRs (which is very sensible).

The error you are experiencing is a consequence of the SONAR_TOKEN that is not available. We will improve the logs so that it fails with a much better description.

You will have to let somebody with access to the repository create an internal pull request of your changes.

Hope that helps,
Tom