azure

Azure-related repository

View the Project on GitHub groovy-sky/azure

How-to deploy SonarQube to Azure (part 2)

Introduction

In the previous chapter we have deployed and configured SonarQube environment on Azure. This time we will provision an Azure DevOps Project and configure CI pipeline to integrate it with SonarQube.

Architecture

In our scenario we will use configuration, which contains following parts:

Prerequisites

For this tutorial we would need to install SonarQube extension from the Marketplace.

If you don’t have existing Azure DevOps project you can easily create a new one. Just go to https://azure.microsoft.com/en-us/services/devops and create a new project:

Next step is SonarQube extension installation:

Implementation

As has been mentioned above for a source code we will use “Azure CLI” repository. Let’s import it to our project:

Once data is imported - we can create a new build pipeline:

There is no need to run “Flake8” and “pytest” pipeline steps, so we can just remove or disable them(use right click to open the menu):

Next, we need to add SonarQube part to the pipeline. As official documentation says - “To analyse your projects, the extension provides 3 tasks that you will use in your build definitions”. Steps are following:

  1. Prepare Analysis Configuration task, to configure all the required settings before executing the build.
  2. Run Code Analysis task, to actually execute the analysis of the source code.
  3. Publish Quality Gate Result task, to display the Quality Gate status in the build summary and give you a sense of whether the application is ready for production “quality-wise”.

Third task is not mandatory, which is why we will skip it and add only “Prepare Analysis Configuration” and “Run Code Analysis” tasks:

Now we need to configure “Prepare Analysis Configuration” step. To do so we need to generate new token on SonarQube server side: Generated token we will use for a new service creation and, as we won’t store sonarqube settings in our source code, manually provide in the pipeline:

Also we will need to specify “working directory” for “Build sdist” task:

By default build pipeline will use for a build multiple Python versions. As enhancement we can set only one version:

Now we can save and queue our build pipeline:

Known limitations

If build fails with “413 Request Entity Too Large” error - when you need to increase NGINX’s upload size limit:

NGINX is running as a service on SonarQube server. To change required parameter we could:

This time we will use second option. Let’s enable it: For a login, please, use “adm1n” for a username and for a password you need to use password which you specified during template deployment from previous article(or if you don’t remember it - just reset it):

Now we can modify required parameter in your preferable text editor (for example “sudo nano /etc/nginx/sites-enabled/default”):

So changes started to work we need to reload NGINX - “sudo systemctl reload nginx”

Results

Once build successfully completes, go to SonarQube to see analysis results:

Useful documentation

https://www.azuredevopslabs.com/labs/vstsextend/sonarqube/

https://docs.sonarqube.org/latest/analysis/overview/

https://www.keycdn.com/support/413-request-entity-too-large