Analyse continue

L'application SonarQube peut être instanciée à partir d'une image docker. Ce qui suit est basé sur le guide officiel pour un système Linux : installing sonarqube from docker.

Récupérer l'image sonarqube:lts-community qui a été copiée de docker.io sur le registry de l'Université de Bordeaux et démarrer l'application :

podman run -d --name sonarqube \
       -p 9000:9000 \
       -v sonarqube_data:/opt/sonarqube/data \
       -v sonarqube_extensions:/opt/sonarqube/extensions \
       -v sonarqube_logs:/opt/sonarqube/logs \
       registry.u-bordeaux.fr/vhub/sonarqube:lts-community

Attention : normalement les volumes créés devraient être conservés entre 2 sessions, mais ici ce n'est pas le cas, car ils sont montés par défaut dans tmp/containers, cf. ~.config/containers/storage.conf pour des raisons d'optimisation des quotas utilisateurs. Généralement les volumes sont montés dans ~/.local/share/containers/storage, un dossier utilisateur persistant.

Cela implique que toute la configuration qui suit ne sera utilisable que le temps de votre session Ubuntu actuelle. Si vous quittez la session, il faudra recommencer la configuration. Ou alors vous créez une sauvegarde de vos données sonarqube juste avant de fermer votre session Linux

mkdir -p ~/sonarqube_data
podman volume export sonarqube_data -o ~/sonarqube_data/data.tar
podman volume export sonarqube_extensions -o ~/sonarqube_data/extensions.tar
podman volume export sonarqube_logs -o ~/sonarqube_data/logs.tar

afin de les réimporter lors d'une prochaine connexion

podman volume create sonarqube_data
podman volume create sonarqube_extensions
podman volume create sonarqube_logs

podman volume import sonarqube_data ~/sonarqube_data/data.tar
podman volume import sonarqube_extensions ~/sonarqube_data/extensions.tar
podman volume import sonarqube_logs ~/sonarqube_data/logs.tar

podman run -d --name sonarqube -p 9000:9000 -v sonarqube_data:/opt/sonarqube/data -v sonarqube_extensions:/opt/sonarqube/extensions -v sonarqube_logs:/opt/sonarqube/logs registry.u-bordeaux.fr/vhub/sonarqube:lts-community

Ouvrir une page internet à l'adresse : http://localhost:9000/. Il faut changer le mot de passe, celui par défaut est admin:admin.

Il faut créer un token côté SonarQube pour permettre d'importer les résultats d'analyse de code avec le programme sonar-scanner. Créer un personal token (User) "heat", voir My Account->Security->Generate Tokens en haut à droite, le sauver dans un fichier et une variable :

echo "squ_blablabla-1234567890" > $HOME/.sonartoken
export SONAR_TOKEN=`cat $HOME/.sonartoken`

Vous pouvez aussi ajouter cet export dans votre script ~/setenv-podman.sh.

Par la suite nous allons analyser du code écrit en C. Par défaut la version "Community" de SonarQube ne prend pas en charge ce langage. Il faut installer le plugin sonar-cxx (version 2.1.1 compatible avec SonarQube 9.9 LTA) :

podman exec sonarqube bash -c 'wget https://gitlab-ce.iut.u-bordeaux.fr/api/v4/projects/14291/packages/generic/sonar-cxx/2.1.1/sonar-cxx-plugin-2.1.1.488.jar -P "$SONARQUBE_HOME"/extensions/plugins/'
# source du plugin sur github : https://github.com/SonarOpenCommunity/sonar-cxx/releases/download/cxx-2.1.1/sonar-cxx-plugin-2.1.1.488.jar
podman restart sonarqube

De retour sur http://localhost:9000/, log in, puis cliquer "I understand the risk".

Si vous voulez voir les données des volumes :

podman exec sonarqube bash -c 'ls "$SONARQUBE_HOME"/data/*'
podman exec sonarqube bash -c 'ls "$SONARQUBE_HOME"/extensions/*'
podman exec sonarqube bash -c 'ls "$SONARQUBE_HOME"/logs/*'

Pour l'analyse statique et dynamique, on va avoir besoin d'un certain nombre d'outils. Plutôt que de les installer directement dans l'environnement natif on va se servir d'une image docker. La recette est ici : dockerfile-sonar-scanner.

Télécharger l'image préconstruite (bien être authentifié sur le registry Gitlab cf. setenv-podman.sh) :

podman pull gitlab-ce.iut.u-bordeaux.fr:5050/but-devops/automatisation/analyse
podman tag gitlab-ce.iut.u-bordeaux.fr:5050/but-devops/automatisation/analyse scanner

À présent vous pouvez instancier un conteneur avec tous les outils nécessaires à l'analyse SonarQube (sonar-scanner, cppcheck, clang, gcov, valgrind, etc) :

podman run -it --name scanner --network="host" -e GITLAB_USER=$USER -e GITLAB_TOKEN=$TOKEN -e SONAR_TOKEN=$SONAR_TOKEN scanner

Dans le conteneur précédemment instancié, exécuter une analyse très simple, un "Hello World" en python.

Créer un script python comme ceci :

cd /builds
mkdir -p hello/
cd hello/
echo 'print("Hello, world!")' > hello_world.py

Tester l'exécution :

python hello_world.py

Maintenant, utilisons sonar-scanner pour analyser ce code source :

sonar-scanner -D"sonar.host.url=http://localhost:9000" -D"sonar.login=$SONAR_TOKEN" -D"sonar.projectKey=helloworld" -D"sonar.sources=./hello_world.py"

Vous devriez voir INFO: EXECUTION SUCCESS. Visitez la page SonarQube project and explorez le projet soumis "helloworld".

Remarquez les deux panneaux "New Code" et "Overall Code". La partie New Code souligne les mesures sur les nouvelles lignes de code par rapport à un état précédent, qui peut être défini de plusieurs manières :

• soit par rapport à la toute première analyse,
• ou par rapport au paramètre sonar.projectVersion,
• ou par rapport à l'état du code sur une autre branche git.

Vous pouvez parcourir les différents onglets, notamment Code qui donne la liste des fichiers analysés et quelques métriques associées.

sonar-scanner est utilisé dans un shell via une CLI (Command Line Interface). On peut ajouter des paramètres à la ligne de commande ou en les stockant dans un fichier sonar-project.properties :

sonar.host.url=http://localhost:9000
sonar.login=squ_blablabla-1234567890
sonar.projectKey=helloworld
sonar.sources=./hello_world.py

Ainsi, vous pouvez lancer l'analyse simplement comme ceci :

sonar-scanner

Notez que les valeurs par défaut sont celles définies dans le fichier, celles passées à la commande complètent ou remplacent celles du fichier (si la même variable est renseignée deux fois).

Cloner le code Heat dans votre conteneur :

cd /builds
git clone https://$GITLAB_USER:$GITLAB_TOKEN@gitlab-ce.iut.u-bordeaux.fr/$GITLAB_USER/heat.git
cd heat/

Lancer l'analyse complète :

HEAT_ROOT=$PWD ./tools/build-test.sh
./tools/analysis.sh

Un certain nombre de rapports sont générés.

• build/heat-build.log : gcc warnings
• build/analyzer_reports/ : clang-sa
• clang-tidy-report : clang-tidy
• heat-cppcheck.xml : cppcheck
• heat-rats.xml : rats
• heat-vera.xml : vera++
• heat-valgrind.xml : valgrind
• heat-junit.xml : xunit report for C/C++
• heat-coverage.xml : coverage C/C++
• plot_junit.xml : xunit report for Python
• plot_coverage.xml : coverage Python

Transmettre les rapports d'analyse sur le serveur SonarQube :

sonar-scanner -X -Dsonar.host.url=http://localhost:9000 -Dsonar.login=$SONAR_TOKEN 2>&1 |tee sonar.log

Pour le moment peu de problèmes sont visibles côté SonarQube, car par défaut les règles C/C++ ne sont pas actives. Nous allons activer les règles à surveiller dans un Quality Profile pour Heat dans la section suivante.

Nous avons besoin de choisir les règles à activer. Créer un Quality Profile (QP). Aller sur la page Quality Profiles, chercher le profile existant dans le langage CXX "Sonar way" et le copier en tant que "heat".

Dans ce nouveau QP, cliquer sur Activate More, enlever les filtres existants, sélectionner le langage CXX dans les filtres, et cliquer sur Bulk Change -> Activate In … -> heat - CXX. Cela va activer l'ensemble des règles disponibles.

Par défaut, votre projet utilise le Quality Profile "Sonar way". Changer cela en allant dans les "Project Settings" du projet Heat et modifier le QP à utiliser pour le langage CXX "Sonar way" -> "heat".

Retransmettre les rapports d'analyse sur le serveur SonarQube :

sonar-scanner -X -Dsonar.host.url=http://localhost:9000 -Dsonar.login=$SONAR_TOKEN 2>&1 |tee sonar.log

Vous devriez voir apparaitre des problèmes dans l'onglet Overview->Overall Code.

Parcourir les issues de type Bugs par exemple.

Une première question à se poser est la question de la visibilité du projet. Est-ce que le projet est libre et donc ouvert, ou privé, avec une licence ? Est-ce que vous souhaitez partager les mesures de SonarQube avec votre communauté ? Si oui alors aller dans les Project Settings -> Permissions et positionner sur "Public". Ainsi, le projet pourra être examiné par tous, sans authentification. Bien sûr au sein d'une entreprise, le serveur pourrait être ouvert pour les employés connectés au réseau entrepris, mais fermé au reste du monde.

Ensuite, vous avez deux onglets New Code et Overall Code qui présentent les principales métriques telles que le nombre de Bugs (robustesse), Vulnerabilities (aspects securité), Code Smells (encourage le respect des standards), Unit tests, Coverage, Duplications.

Chaque mesure est cliquable, on peut explorer la liste des :

• issues

• measures : métriques et graphes résumant la situation

  • cercles en haut à droite : fichiers à prioriser et corriger
  • cercles en bas à gauche : plutôt sains

  

• activity: tendances historiques de l'évolution des mesures après plusieurs analyses

La Quality Gate (QG) informe de façon binaire (OK, Not OK) si la qualité du code est pire qu'avant. Par exemple, si de nouveaux bugs apparaissent entre deux analyses sur du nouveau code ou si la couverture de code devient inférieure à 80% alors la QG devient rouge et les développeurs sont notifiés pour corriger le nécessaire et faire en sorte de faire repasser la QG en vert.

La notion de nouveau code (New Code) sert à pouvoir mesurer l'évolution de la qualité du logiciel. Elle peut être définie de différentes manières : comparaison entre deux branches, comparaison par rapport à la dernière release. On peut indiquer à SonarQube le numéro de version en cours afin de définir le nouveau code avec sonar.projectVersion. Si on change de 1.0 à 2.0 alors, pour les analyses suivantes, le nouveau code considéré sera celui injecté depuis la release 1.0. Voir defining new code.

La section mesures permet d'avoir une vue synthétique de la qualité du code vue fichier par fichier avec des graphes, différentes vues dossiers/sous-dossiers, à propos des bugs, vulnérabilités, couverture, duplications, tailles, complexités. Voir aussi metric definitions.

En cliquant sur Issues on obtient une liste de tous les problèmes relevés (bugs, vulnerabilities, code smells). Le panneau de gauche permet de filtrer par type d'issue.

Cette page permet de vérifier les potentiels problèmes détectés par les différents outils (sonar-scanner, warning gcc, clang-sa, clang-tidy, cppcheck, valgrind, etc) et pour les gérer. Faut-il corriger ces problèmes ? Vérifier les faux positifs. Par défaut les nouveaux problèmes ont un statut Open. Le but est de réduire le nombre de problèmes ouverts. La première chose à faire dans l'interface est de choisir quelles erreurs corriger dans un futur proche ou non.

1. Les erreurs à corriger rapidement sont étiquetées Confirmed. Si dans la prochaine analyse l'erreur n'est plus visible dans les rapports alors SonarQube va automatiquement la basculer en Fixed et Closed.
2. Les autres erreurs peuvent être classées différemment. Pourquoi ne pas corriger rapidement ces erreurs ? Est-ce parce que :
   • c'est un faux positif, à basculer dans la catégorie false positive
   • l'erreur est connue, mais on souhaite conserver le code tel quel, car on a de bonnes raisons, à étiqueter won't fix

Remarque : les erreurs Closed sont gardées 30 jours dans la base de données.

Il y a plein de façons de filtrer les erreurs via le panneau de gauche :

• Type : Bug, Vulnerabilities, Code Smells
• Resolution and Status : Unresolved, Fixed , Open, Closed, …
• Rule : the issue name
• Directory, File
• Assignee, Author
• Language

L'onglet Code permet de naviguer dans les répertoires et de voir des métriques fichier par fichier : taille, nombre d'issues, pourcentage de couverture et duplications.

L'onglet Activity permet d'avoir une vue sur l'évolution des métriques (bugs, vulnerabilities, code smells) dans le temps entre les versions (releases par exemple).

Vous pouvez vous inscrire aux notifications par e-mail qui vous informent des nouveaux résultats d'analyse et donner un lien vers les nouvelles issues du projet.

Allez dans "My Account" (coin supérieur droit) -> Notifications -> Notifications per project, écrivez le nom de votre projet dans la barre de recherche, sélectionnez-le puis cochez les cases.

Des badges peuvent être ajoutés dans certaines pages web afin d'afficher les mesures de qualité du code.

Consultez l'onglet More -> SoftVis3D Viewer si le plugin a été installé.

L'analyseur C/C++ de SonarQube est un service payant (cf. SonarCFamily plugin). Ce plugin ne peut pas être utilisé dans la version communautaire que nous avons instanciée ici. Avec ce plugin, nous avons accès à quelques issues SonarQube (lors de l'analyse avec sonar-scanner) et nous pouvons importer de nombreux autres rapports provenant d'analyseurs externes. C'est bien, mais nous n'avez pas accès à l'analyseur "officiel" SonarQube C/C++ qui est sûrement intéressant lui aussi.

La bonne nouvelle ? Il existe un serveur SonarQube public, sonarcloud pour des projets opensource et qui donne accès au plugin SonarCFamily.

Si vous avez un projet open source à analyser et que vous voulez voir ce que donne l'analyse sonar-scanner avec le plugin SonarCFamily, vous pouvez consulter la documentation sonarsource.

Voir par exemple le projet SimGrid.

Coverity est un autre analyseur qui est normalement un service payant, mais qui donne accès à un serveur public pour les projets opensource, voir :

• page principale
• connexion

Télécharger l'application cov-build.

COVERITY_TOKEN="XEJaJ1cAnqW-9M_zkmxd7w"
wget --no-check-certificate https://scan.coverity.com/download/linux64 --post-data "token=$COVERITY_TOKEN&project=Heat" -O coverity_tool.tgz
tar xvf coverity_tool.tgz
sudo ln -s -f $PWD/cov-analysis-linux64-*/bin/cov-build /usr/local/bin/cov-build

Construire et analyser le projet Heat avec la commande cov-build :

git clone https://gitlab-ce.iut.u-bordeaux.fr/but-devops/heat.git
cd heat/
mkdir -p build
cd build
cmake ..
make clean
cov-build --dir cov-int make -j 4

Créer une archive compressée des résultats :

tar czvf heat.tgz cov-int

Transmettre le rapport d'analyse sur le serveur Coverity :

curl --form token=$COVERITY_TOKEN --form email=florent.pruvost@inria.fr --form file=@heat.tgz --form version="`git rev-parse --short HEAD`" --form description="" https://scan.coverity.com/builds?project=Heat

Consulter les résultats sur le dashboard Coverity, suivre le lien "View Defects".

Fonctionnalités :

• Service payant si le projet n'est pas open source
• Langages : C/C++, C#, Java, Javascript, PHP, Python, .NET Core, ASP.NET, Objective-C, Go, JSP, Ruby, Swift, Fortran, Scala, VB.NET, iOS, TypeScript
• Bien intégré dans les IDE, prend en charge la plupart des compilateurs
• Détection fine
  • des bugs (analyse statique)
  • des problèmes de concurrence (accès simultané aux données, interblocages, race conditions)
  • des problèmes de sécurité …