Si vous avez eu l’occasion de visiter les dépôts GitHub de projets open source tel que .NET Core, vous avez sans doute remarqué la présence de badges dans le contenu de leur fichier Readme. Les badges sont ces petites images représentant l’état d’un projet. Il en existe beaucoup, pour des indicateurs divers et variés. Concernant les projets .NET, les badges les plus communs sont :
- Le statut du dernier build
- La version actuelle du package NuGet
- Le pourcentage de couverture de code
Certaines de ces informations sont issues d’un processus d’intégration continue. Affichées sur la page d’accueil de votre projet, elles peuvent inciter les visiteurs et les utilisateurs à s’impliquer : corrections de bugs et améliorations via des pull requests. Elles peuvent aussi témoigner de la qualité du projet et ainsi augmenter sa popularité.
Voyons comment créer ces badges afin que vous aussi, vous puissiez les intégrer dans vos projets .NET.
Afficher le statut du dernier build grâce à AppVeyor
AppVeyor est une plateforme d’intégration continue en ligne qui permet de compiler les projets .NET et également d’exécuter les tests unitaires de façon automatique. Il suffit de vous inscrire puis d’y référencer vos dépôts de provenance diverses (Visual Studio Team Services, GitHub, BitBucket, etc.). AppVeyor est gratuit pour les projets open source. Si vous souhaitez l’utiliser de manière privée, vous devrez souscrire à un abonnement.
Sur des projets contenant une seule solution Visual Studio, AppVeyor est capable de se débrouiller pour compiler la solution et découvrir les tests unitaires par lui-même, à chaque push. Cela dit, rien ne vous empêche de mettre les mains dans le cambouis et d’explorer tous les paramètres. Configuration de build, solutions multiples, scripts à exécuter avant et après un build, version de Visual Studio, variables d’environnements… AppVeyor fournit énormément d’options que je vous laisse découvrir par vous-même.
Une fois que votre projet aura été compilé pour la première fois par AppVeyor, il vous suffira de vous rendre dans la section “Badges” des paramètres du projet et de copier l’URL du badge pour la branche voulue, au format d’image qui vous convient le mieux.
Indiquer la dernière version disponible de votre package sur NuGet
Shields.io est un service entièrement dédié à la création de badges en tous genres. Il est compatible avec notre gestionnaire de packages préféré, NuGet. Il vous suffira de modifier l’url suivante en précisant le nom de votre package :
// Exemple : https://img.shields.io/nuget/v/Xamarin.Forms.svg
https://img.shields.io/nuget/v/{VotrePackageId}.svgSi vous souhaitez changer la couleur, il suffit de la spécifier au format hexadécimal dans le paramètre GET « colorB » : https://img.shields.io/nuget/v/{VotrePackageId}.svg?colorB=44cc11
Afficher la licence open source
Là encore, nous allons utiliser Shields.io et la possibilité de créer un badge avec du texte personnalisé, en l’occurrence le nom de la licence utilisée par votre projet. Le format est le suivant (sans les accolades) :
https://img.shields.io/badge/{texteGauche}-{texteDroite}-{codeCouleurHexa}.svgPour la licence Apache 2.0, l’URL du badge est donc :
https://img.shields.io/badge/License-Apache_2.0-44cc11.svg
Afficher la couverture de code grâce à Coveralls
Coveralls est une autre plateforme d’intégration continue en ligne dédiée à la qualité du code source. Elle permet, entre autres, d’historiser la couverture de code de vos projets afin de générer un graphique et des statistiques. Il ne s’agit pas d’un service limité aux technologies .NET et on peut s’en servir pour tous les langages de programmation qui supportent le calcul de couverture de code. Là encore, il s’agira de s’y inscrire et de lier votre dépôt de code source.
Le fonctionnement de Coveralls avec les projets .NET est le suivant :
- Il faut utiliser l’outil OpenCover, qui va générer un rapport XML de couverture de code pendant l’exécution de vos tests unitaires,
- Puis, le package NuGet Coveralls.net se chargera de le convertir et de le soumettre à Coveralls.io dans un format qu’il pourra interpréter.
Voici l’équivalent en lignes de commande simplifiées :
# xunit.console.exe peut être remplacé par votre exécuteur de tests unitaires préféré (MSTest, NUnit, etc.)
OpenCover.Console.exe -register:user -target:xunit.console.exe -targetargs:"MonProjet.Tests.dll -noshadow -appveyor" -filter:"+[MonProjet*]*" -output:coverage.xml
# Le token Coveralls doit être généré dans les réglages de sécurité, sur coveralls.io
# Des informations concernant le dernier commit peuvent être fournies, voir la suite de cette section
csmacnz.Coveralls.exe --opencover -i coverage.xml --repoToken {tokenCoveralls}Ces commandes peuvent être exécutées sur votre poste local, en utilisant les bons chemins de fichiers – qui ont été omis ci-dessus pour plus de clarté. Mais, afin de calculer la couverture de code à chaque commit et push, l’idéal serait d’intégrer ces commandes lors de la compilation par AppVeyor. C’est faisable en remplaçant l’exécution des tests automatiques par un script PowerShell contenant les commandes ci-dessus.
La publication de la couverture de code depuis AppVeyor peut être enrichie par les informations du commit qui a déclenché la compilation, accessibles sous la forme de variables d’environnement :
csmacnz.Coveralls.exe --opencover -i coverage.xml --repoToken $env:COVERALLS_REPO_TOKEN --commitId $env:APPVEYOR_REPO_COMMIT --commitBranch $env:APPVEYOR_REPO_BRANCH --commitAuthor $env:APPVEYOR_REPO_COMMIT_AUTHOR --commitEmail $env:APPVEYOR_REPO_COMMIT_AUTHOR_EMAIL --commitMessage $env:APPVEYOR_REPO_COMMIT_MESSAGE --jobId $env:APPVEYOR_JOB_IDPour aller plus loin
Dans cet article, nous n’avons mentionné que quelques types de badges et vu une petite partie des outils AppVeyor, Coveralls.io ainsi que les utilitaires qui vont avec. Vous trouverez ci-dessous quelques liens qui vous permettront d’approfondir le sujet.
