Analyse continue
Table of Contents
- 1. Introduction
- 2. Rapports intégrés dans Gitlab
- 3. Analyse plus poussée avec SonarQube
- 4. Nettoyage
Inspection continue de la qualité :
- Tests unitaires et badge de couverture dans Gitlab
- Analyse plus poussée avec SonarQube
1 Introduction
Vérifiez que vos pipelines sont toujours fonctionnels.
Pour cela trois pré-requis à vérifier :
- le "personnal access token" gitlab,
- le service
gitlab-runner
, - le service
podman
.
Pour avoir accès à votre token et à la bonne configuration podman vous pouvez utiliser le script setenv-podman.sh,
commande à taper dans chaque nouveau terminal ou à ajouter dans votre .bashrc
:
source ~/setenv-podman.sh # rappel : un personal access token valide doit se trouver dans le fichier ~/.gitlabtoken
Ensuite pour lancer le service gitlab-runner
soit le service est déjà configuré et fonctionnel
systemctl --user status gitlab-runner.service # répond : active (running)
soit vous le lancez manuellement dans un nouveau terminal
~/gitlab-runner run
Enfin pour valider que les pipelines fonctionnent, lancer un pipeline. Par exemple manuellement via la page Build -> Pipelines -> Run pipeline, en choisissant la branche 'auto' du projet Heat sur laquelle vous avez déjà travaillé.
Vous pouvez repartir sur votre branche 'auto' de Heat tout en commentant certains jobs dans votre fichier
.gitlab-ci.yml
, par exemple : gtest (et le needs: ["gtest"] dans build), release, deploy, pages. Commiter, pousser
pour vérifier que votre pipeline composé à minima de buildenv, build et test fonctionne.
2 Rapports intégrés dans Gitlab
2.1 Tests unitaires
La liste des tests unitaires peut être longue et il est pratique d'avoir une vue synthétique du statut des tests (succès/échec) des derniers commits de notre branche. Il existe une fonctionnalité Gitlab pour visualiser le rapport de tests directement sur la page du pipeline (cf. unit test report).
Mettre en place cette technique sur votre projet Heat. Pour cela, modifier la commande ctest dans .gitlab-ci.yml
afin d'ajouter la génération d'un rapport de tests au format junit. Ensuite ajouter ce fichier aux artefacts comme
démontré dans la documentation Gitlab :
script: - ctest -V --test-dir build --output-junit ctest.xml artifacts: when: always reports: junit: build/ctest.xml
Vous devriez voir "Uploading artifacts as "junit" to coordinator" dans le log du job test. Rendez-vous sur la page du dernier pipeline exécuté, onglet Tests (à côté de ceux Pipeline ou Jobs), pour voir le résultat.
Figure 1: Rapport des tests unitaires sur Gitlab
2.2 Couverture des tests
Les tests de couvertures informent sur le pourcentage de lignes couvertes (ou % de fonctions, ou % d'embranchement tels que les if, switch) par les tests unitaires. C'est une bonne pratique de développement de vérifier que les nouvelles lignes de codes sont bien couvertes par des tests.
Gitlab permet de récupérer une métrique de couverture qu'on aura calculé pendant un des jobs (cf. test coverage). De plus avec ce rapport les relecteurs d'une "merge request" pouront vérifier si les nouvelles lignes de code proposées sont couvertes on non (bandeau vert ou orange sur le côté gauche du code source dans l'onglet Changes).
Ajouter au job test le rapport de couverture. Pour cela, il faut ajouter le paquet gcovr dans l'image docker de test, forcer sa reconstruction en enlevant les éventuelles conditions affectant le job buildenv.
Ajouter le nécessaire aux job build : compiler l'application Heat avec l'option de couverture de code
-DCMAKE_C_FLAGS="--coverage"
.
Ensuite ajouter le nécessaire au job test :
- génération du rapport de couverture au format cobertura avec gcovr,
- ajouter
coverage: /^\s*lines:\s*\d+.\d+\%/
pour indiquer à Gitlab (regexp sur le log) comment récupérer le pourcentage de couverture global sur le code source, - ajouter le rapport cobertura dans les artefacts.
script: - ctest -V --test-dir build --output-junit ctest.xml - cd build/ && gcovr --xml-pretty --exclude-unreachable-branches --print-summary -o coverage.xml --root ${CI_PROJECT_DIR} coverage: /^\s*lines:\s*\d+.\d+\%/ artifacts: when: always reports: junit: build/ctest.xml coverage_report: coverage_format: cobertura path: build/coverage.xml
Vous devriez observez le pourcentage sur la page du job test dans les metadonnées sur la droite.
Figure 2: Pourcentage de couverture
3 Analyse plus poussée avec SonarQube
3.1 Généralités
SonarQube est un outil d'analyse de la qualité d'un logiciel. Un programme nommé sonar-scanner
est lancé sur la
machine cible permettant de faire tourner le logiciel, à la racine du code source afin de réaliser l'analyse, ensuite
les rapports de bugs et divers métriques sont téléversés vers un serveur où un tableau de bord web permet de
visualiser et partager la qualité et la maturité du logiciel.
Plusieurs éléments peuvent être reportés : taille du code source, détection de duplication, problèmes basés sur des analyses de code statiques (recherche de bugs potentiels sur la connaissance du code source) et dynamiques (exécution du binaire).
Plusieurs versions de SonarQube sont distribuées : une libre (opensource, gratuite) "Community" avec une limitation sur certaines fonctionnalités, et d'autres payantes (voir Plans & Pricing). SonarCloud est aussi une instance disponible en ligne gratuitement pour les projets libres.
Langages supportés : C, C++, C#, CSS, Flex, Go, HTML, Java, JavaScript, Kotlin, PHP, Python, Ruby, Scala, Swift, XML, etc, voir list of supported languages. Certaines fonctionnalités additionnelles peuvent être obtenues via un système de plugins.
3.2 Analyse avec SonarQube
3.2.1 Image docker de SonarQube
L'application SonarQube peut être instanciées à 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.
Ouvrir une page internet à l'adresse : http://localhost:9000/. Il faut changer le mot de passe, celui par défaut est admin:admin.
Figure 3: Page d'accueil
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/*'
3.2.2 Environnement d'analyse
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
A 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
3.2.3 Hello World SonarQube
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).
3.3 Scan complet du programme Heat (C/C++) avec des analyseurs externes
Expérimentons l'analyse statique et dynamique sur le code Heat écrit en C, qui fournit une implémentation basique pour résoudre l'équation de la chaleur.
L'analyse statique tend à trouver des problèmes dans le code source simplement basé sur les fichiers textes et révèle de possibles erreurs syntaxiques, variables non initialisées lues, déréférencement de pointeurs, fuites mémoires, duplications, réduction de portée, non respect de conventions, etc.
L'analyse dynamique permet de vérifier un programme en exécutant les binaires. Les tests unitaires et d'intégrations font partis de l'analyse dynamique, tout comme les mesures de couverture, la vérification mémoire, la vérification des threads, etc.
3.3.1 Télécharger Heat avec git, compiler Heat et lancer le script d'analyse
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.
3.3.2 Créer un Quality Profile
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 existant, 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".
Re-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
Vous devriez voir apparaitre des problèmes dans l'onglet Overview->Overall Code.
Parcourir les issues de type Bugs par exemple.
3.4 Etude qualitative du code source en utilisant SonarQube
La documentation SonarQube.
3.4.1 Overview
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 entreprise 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 respects des standards), Unit tests, Coverage, Duplications.
Chaque mesure est cliquable, on peut explorer :
- liste des "issues"
measures, avec des métriques et des graphes résumant la situation
- cercles en haut à droite : fichiers à prioriser et corriger
- cercles en bas à gauche : plutôt sains
- activity: tendances historique 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évelopppeurs 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.
- Exercices
- Quelles sont les notes sur l'ensemble du code pour la robustesse, la sécurité et la maintenabilité ?
Créer une nouvelle Quality Gate "heat" avec en condition sur l'"Overall Code" :
- Coverage is less than 80%,
- Reliability Rating is worse than A.
Appliquer cette nouvelle QG sur le projet Heat et ré-exécuter le scan : le statut de la Quality Gate est Failed car la couverture est aux alentours de 50% et puisqu'il y a des bugs.
3.4.2 Measures
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.
- Exercices
- Sur le graph project overview quelle est la signification de la couleur des cercles et taille du cercle pour chaque fichier ?
- Quel fichier devrait être considéré en premier pour améliorer la maintenabilité ?
- Quel fichier important semble ne pas être couvert par les tests unitaires (voir Coverage -> Overall -> View as: Treemap) ?
- Quel langage est principalement analysé dans heat (Size->Lines of code), combien de lignes de codes pour chaque langage ?
- La densité de duplication vous semble-elle correcte (saine) ?
3.4.3 Issues
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.
- 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.
- 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 des bonnes raisons, à étiqueter won't fix
Remarque : les erreurs closed sont gardées 30 jours dans la base de donnée.
Il y a pleins 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
- Exercices
Le but est de corriger quelques problèmes dans Heat. Vous allez devoir éditer et modifier des fichiers et re-exécuter l'analyse.
Filtrer les Issues de type Bugs (voir Software Quality -> Reliability) et les étiqueter Confirm. Ensuite commencer par corriger celles que vous pouvez parmis les trois avant de soumettre une nouvelle analyse.
- Corriger l'issue "Value stored to 'err' is never read"
- Corriger l'issue "Assigned value is garbage or undefined"
- Enlever aussi l'allocation qui n'est jamais libérée
xalloc (u_tmp, ...)
- Corriger la macro
xalloc
.
Côté éditeur de texte il y a vim d'installé dans le conteneur. Sinon commiter vos modifs dans une branche (ex : auto) et faites
git pull
dans le conteneur scanner. Vous pouvez utiliser les scripts existants pour refaire toute l'analyse sur le nouveau code source :HEAT_ROOT=$PWD ./tools/build-test.sh ./tools/analysis.sh sonar-scanner -X -Dsonar.host.url=http://localhost:9000 -Dsonar.login=$SONAR_TOKEN 2>&1 |tee sonar.log
Essayer maintenant de corriger votre Quality Gate. Pour cela il faut une couverture > 80%. Vous avez surement remarqué que le fichier
heat_par.c
n'est pas couvert par les tests. Pour activer cette partie du code il faut activer l'option MPI, éditer le fichiertools/build-test.sh
et activer MPI (cf.-DHEAT_USE_MPI=ON
). Après une nouvelle analyse complète la QG devrait être reglée.Essayer de filtrer par "Rule", les erreurs qui traitent d'"Warn when a variable is unused" ou "The scope of the variable can be reduced" (cppcheck) et les régler. Une fois corrigées, vous devriez les voir comme Fixed dans les Issues avec filtre Resolution=Fixed.
3.4.4 Code
L'onglet Code permet de naviguer dans les répertoires et de voir des metriques fichier par fichier : taille, nombre d'issues, pourcentage de couverture et duplications.
3.4.5 Activity
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).
3.5 Automatiser l'analyse SonarQube dans votre pipeline Gitlab CI
Dans une démarche d'amélioration de la qualité en continue vous pouvez maintenant automatiser ce processus d'analyse dans votre pipeline gitlab-ci.
Dans votre fichier .gitlab-ci.yml
commenter les jobs existant build et test, ajouter un
stage "sonar" après "test", et ajouter le job suivant :
sonar: stage: sonar image: gitlab-ce.iut.u-bordeaux.fr:5050/but-devops/automatisation/analyse script: - HEAT_ROOT=$PWD ./tools/build-test.sh - ./tools/analysis.sh - sonar-scanner -X -Dsonar.host.url=http://localhost:9000 -Dsonar.login=$SONAR_TOKEN 2>&1 |tee sonar.log
Il y a deux petites configurations à faire avant de pousser ce nouveau job sur Gitlab.
- Pour que votre conteneur podman ait accès au serveur SonarQube local (http://localhost:9000) il faut ajouter
network_mode = "host"
dans votre fichier$HOME/.gitlab-runner/config.toml
dans la section[runners.docker]
. Re-démarrer le runner avec./gitlab-runner run
(ousystemctl --user restart gitlab-runner
). - Il faut ajouter une variable d'environnement contenant le token SonarQube au pipeline gitlab-ci. Pour cela aller dans la section Settings->CI/CD->Variables de votre projet Gitlab Heat. Cliquer sur "Add variable" et mettre Key=SONAR_TOKEN et dans Value copier-coller votre token SonarQube. Vous pouvez mettre Masked pour éviter l'affichage de la valeur dans les logs des pipelines.
Vous pouvez commiter et pousser votre branche "auto" sur Gitlab et vérifier que votre job d'analyse se lance avec succès.
- Corriger les issues sonarqube avec commit+push sur votre branche auto.
3.6 Bonus
3.6.1 Notifications par email
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.
3.6.2 Bagdes
Des badges peuvent être ajoutés dans certaines pages web afin d'afficher les mesures de qualité du code.
3.6.3 3D view
Consultez l'onglet More -> SoftVis3D Viewer si le plugin a été installé.
3.6.4 SonarQube public server for opensource softwares
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.
3.6.5 L'alternative Coverity
Coverity est un autre analyseur qui est normalement un service payant mais qui donne accès à un serveur public pour les projets opensource, voir :
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)
- Problèmes de concurrence (accès simultané aux données, inter-blocages, race conditions)
- Les problèmes de sécurité, …
4 Nettoyage
# stopper le conteneur podman stop sonarqube # supprimer le conteneur podman rm sonarqube # supprimer l'image podman rmi sonarqube # nettoyer les volumes (ne pas le faire si on veut garder la config sonarqube: password, plugins, quality profiles, analyses précédentes, etc) # podman volume prune