Code Analysis with SonarCloud

SonarCloud has quickly become the industry standard for code analysis, especially on projects we are involved with. SonarCloud is the cloud edition of SonarQube. Today we are going to dive in and look at how do we can get it work.

“I feel the success that we have had with code analysis has been clear enough, that I will say plainly it is irresponsible to not use it.”

John Carmack (https://www.gamasutra.com/view/news/128836/InDepth_Static_Code_Analysis.php)

(Static) Code Analysis is the process of scanning source code for commonly known vulnerabilities and potential errors. These can include security, performance, and error-prone code – in short, it can improve your code quality. Why wouldn’t you try to make your code as high quality as possible? SonarQube is a market leading tool to help us achieve these goals. The version of SonarQube we will be using is SonarCloud, and we will be integrating this into our build pipeline and pull requests.

Setting up SonarCloud

We start by browsing to https://sonarcloud.io/sessions/new. To use the free edition of SonarCloud, we require a “school or work live account”. When we log in, it confirms what permissions the app will have to our account.

We then have a blank slate. We start by creating a new organization, in this case “SamSmithNZ”, and a new project key “SamLearnsAzure”. As this is a public project, we leave the visibility to public.

In the account section, we need to create a new security token

We add a new token name “SamLearnsAzure”, and make a note of the new key that is produced – we will use this to connect to our instance later.

Back in Azure DevOps, we add a new marketplace item for “SonarCloud” – you will need to be a collection administrator to install this.

With this installed, we create a service connection in our project service connections, creating “SonarCloud Connection”, and using the token we generated from the SonarCloud security token page.

Next, we create a quick, and temporary, build pipeline, with the visual UI in Azure DevOps, add the tasks and extract their YAML we need for the tasks. We create three tasks:

• “Prepare analysis on SonarCloud”: added before the build task
• “Run Code Analysis”: added after the build task
• “Publish Quality Gate Result”: added after the “run code analysis” task

The YAML for the three tasks is below:

- task: SonarSource.sonarcloud.14d9cde6-c1da-4d55-aa01-2965cd301255.SonarCloudPrepare@1
  displayName: 'Prepare analysis on SonarCloud' 
  inputs: 
    SonarCloud: 'SonarQube connection' 
    organization: samsmithnz 
    projectKey: SamLearnsAzure

- task: SonarSource.sonarcloud.ce096e50-6155-4de8-8800-4221aaeed4a1.SonarCloudAnalyze@1 
  displayName: 'Run Code Analysis on SonarCloud' 

- task: SonarSource.sonarcloud.38b27399-a642-40af-bb7d-9971f69712e8.SonarCloudPublish@1 
  displayName: 'Publish Quality Gate Result on SonarCloud'

With the YAML integrated in our main build, we run the build, and watch it fail right away. After some research, we discover it’s related to the .Net Core project file format.

To correct this error, we add a ProjectGuid property to each of the project files we want the code analysis to run on. We generate a random Guid and use it with the following data to each project file

<ProjectGuid>{50dd37ad-58dd-4697-84ec-f28fb5935b50}</ProjectGuid>

Here is the result for context, we have added our code to the same property group as the target framework, but it can be put in any of the property groups.

With this fixed, we run the build again and watch it complete successfully!

On the “Extensions” tab of the finished build, we can see the “SonarCloud Analysis Report”, which in this case has noted a change in quality. This is great, but now we need our pull request to fail if the quality of our build fails.

Creating a quality gate in a Pull Request

We want to create the quality gate in our pull request, so if there is a significant change in code quality, the pull request will fail. After all, the goal of a pull request is to protect the main branch. To start, we need to create a personal access token, so that Azure DevOps can connect to SonarCloud. In Azure DevOps, we click on our profile picture in the top right, and select “Security”.

This shows our current personal access tokens, where we will create a new token, naming it “SonarCloudPersonalAccessToken”. For the scope, all we need to enable is “Code (read and write)”

This creates a new personal access token, which we make note of for later.

In SonarCloud, we click on the “administration” link, and select “General settings”

In the menu of languages that appears, we find and select “Pull Requests”

In the Pull Request details, we select “VSTS” as the provider, and add in our personal access token we created earlier.

Now in the branch policies, we create a new “additional service” status policy

In the dropdown, according to the documentation, “SonarCloud/quality gate” should appear, but we couldn’t get this to show. Fortunately, you can just type in “SonarCloud/quality gate”, which still works great. [12-Jun addition]: We also check the “required” policy requirement, and the “reset conditions”, so that the quality gate will be rechecked for each pull request update.

Now we create a new Pull Request, and note that there is a new “Quality Gate” branch policy that is tested before the Pull Request is completed.

We review the pull requests build, and in the extensions tab, we find that the SonarCloud Analysis Report is now showing success.

Heading back to the SonarCloud dashboard, we can see a status of all current items. There are currently 26 “bugs”, items SonarCloud we are recommended to address. We can see there “4 hours” of work – this is an estimate of how long it would take to address these items. In the center column, we can see new code compared to the base code – this is giving us an idea of what recent code changes are doing to our project – in this case, not much, which is perfect.

If we dive in, we can see more details.

Opening one of our files, we can see it’s recommending we remove the boolean comparison, classifying the comparison as “clumsy”, and a “5 min effort” to correct. We can even assign the issue to a user. There is a lot to dig into here (4 hours worth, apparently), that we will continue to examine.

Wrap up

We’ve added SonarQube analysis to our code with SonarCloud, and we have quality gates on our pull requests to prevent significant degradation of our main branch. With SonarCloud, we have even more confidence in our DevOps pipeline, and that any changes we make to our code, will be of a high quality and not break the main branch.

Note that we continued this a few weeks later, where we customized rule sets and quality gates.

References

• SonarCloud marketplace item: https://marketplace.visualstudio.com/items?itemName=SonarSource.sonarcloud
• SonarCloud build hint: https://stackoverflow.com/questions/50479716/the-following-projects-do-not-have-a-valid-projectguid-and-were-not-built-using
• SonarCloud/Azure DevOps lab: https://www.azuredevopslabs.com/labs/vstsextend/sonarcloud/
• Integrating SonarCloud with Azure DevOps Pull Requests: https://writeabout.net/2019/04/18/use-pull-request-decoration-in-azure-devops-with-sonarcloud/
• John Carmack quote: https://www.gamasutra.com/view/news/128836/InDepth_Static_Code_Analysis.php
• Featured image credit: https://www.perforce.com/sites/default/files/image/2018-06/image-blog-what-is-static-analysis.jpg