Photo by Markus Winkler — Unsplash

Quality of code is quality of life: Python Code Analysis on Azure DevOps with SonarQube

It cannot be denied: the life quality of a programmer is deeply correlated with the quality of the code them and their teammates work with. Everybody knows the pain of having to debug code full of code smells. We all know as well that, at least once, we were the cause of those code smells.

Qui Custodiet Ipsos Custodes

It is then quite common to have someone to be the code quality custodianHaving a quality custodian has its drawbacks. Even the custodian can make mistakes or might turn into a bottleneck.

Here SonarQube comes into play: it is a tool that can be used to analyze the quality of the code and to provide a report that lists code smells and bugs.

SonarQube: What is it?

SonarQube is an open-source platform developed by SonarSource for continuous inspection of code quality to perform automatic reviews with static analysis of code to detect bugs, code smells, and security vulnerabilities. It offers reports on duplicated code, coding standards, code coverage, code complexity, comments, bugs, and security vulnerabilities.

It is possible to create a pipeline triggered by each push to any branch of a repository that will analyse both the new code and the whole repository to see some information regarding the aforementioned metrics.

To do so, we need to:

1. Let SonarQube know we want to create a project, that is, the analysis of a repo
2. Create an Azure DevOps build Pipeline that is executed every time an edit is done on certain branches of the repo; this pipeline will run tests and trigger the code analysis by Sonar Qube
3. Create a Branch Policy. This policy defines which branches should trigger the Pipeline. For example, you may set the policy on `main` branch so that every PR pointing to `main` will trigger the Pipeline at every commit
4. Enjoy

1 Create a project on SonarQube

• Go to SonarQube Project Page and click on New Project->Azure DevOps

• Select the repo you want to put under SonarQube Analysis, in this case, we have chosen the ML repository

Create a token by choosing a token name and then saving the output. This token will be needed in the YAML file that defines the Azure DevOps build pipeline

Select the type of project (eg. python) and Linux as OS (this is not strictly necessary, but it outputs some parameters that will be needed later

2 Create a Pipeline

To create the pipeline it is first necessary to create a YAML file describing the steps of the pipeline, to do so it is possible to use this template:

pool:
name: Azure Pipelines
variables:
EnginePath: ‘SonarTest’
cliProjectKey: ‘YOUR_PRJ_KEY’
cliProjectName: ‘YOUR_PRJ_NAME’
steps:
- checkout: self # self represents the repo where the initial Azure Pipelines YAML file was found
fetchDepth: 1
- task: UsePythonVersion@0
displayName: ‘Use Python 3.9’
inputs:
versionSpec: 3.9
- bash: |
pip install — upgrade pip
pip install -r ./$(EnginePath)/requirements.txt
pytest — junitxml=./$(EnginePath)/test.xml — cov=. — cov-report=xml $(EnginePath)
if [ $? != 0 ]; then
echo “Some tests fails. Please check the report.”
fi
displayName: ‘Unit Test’
- task: SonarSource.sonarqube.CODE.SonarQubePrepare@4
displayName: ‘Prepare analysis on SonarQube’
inputs:
SonarQube: ‘P0-SonarQube’
scannerMode: CLI
configMode: manual
cliProjectKey: $(cliProjectKey)
cliProjectName: $(cliProjectName)
cliSources: $(EnginePath)
extraProperties: |
sonar.python.coverage.reportPaths=$(System.DefaultWorkingDirectory)/coverage.xml
sonar.python.xunit.reportPath=$(System.DefaultWorkingDirectory)/$(EnginePath)/test.xml
- task: SonarSource.sonarqube.CODE.SonarQubeAnalyze@4
displayName: ‘Run Code Analysis’
- task: SonarSource.sonarqube.CODE.SonarQubePublish@5
displayName: ‘Publish Quality Gate Result’
- task: PublishTestResults@2
displayName: ‘Publish Test Results’
inputs:
testResultsFiles: ‘**/$(EnginePath)/test.xml’
failTaskOnFailedTests: true
- task: PublishCodeCoverageResults@1
displayName: ‘Publish code coverage’
inputs:
codeCoverageTool: Cobertura
summaryFileLocation: ‘**/coverage.xml’
pathToSources: ‘$(System.DefaultWorkingDirectory)’
failIfCoverageEmpty: true

modifying as needed the `cliProjectKey` and `cliProjectName` variables at the beginning. Then, on azure DevOps:

• Go on Pipelines -> Pipelines

• Click on “New Pipeline”

• Select Azure Repos Git

• Select the correct repo

• Select “Existing Azure Pipeline YAML file”

• Link the branch containing the YAML file from which we want to create the pipeline and then the specific file.

3 Create a branch policy

The last step is the creation of a branch policy that triggers the created pipeline for every Pull Request, this can be done by a DevOps admin by selecting a repo, the relative branch an then clicking on the three dots to open the branch policies tab.

4 Enjoy

You are now ready to start the analysis of your code (and to be under the merciless rule of a bot with no mercy).

Sources and Docs

Here you can find some links to the documentation of SonarQube[1][2] and Azure DevOps [3][4] that we used create this article.