
Vous aimez GitLab et dĂ©testez les erreurs ? Vous souhaitez amĂ©liorer la qualitĂ© du code source ? Alors vous ĂȘtes au bon endroit. Aujourd'hui, nous allons vous expliquer comment configurer l'analyseur C# PVS-Studio pour vĂ©rifier les demandes de fusion. Ă tous, nous souhaitons une ambiance de licorne et une bonne lecture.
est un outil pour détecter les erreurs et les vulnérabilités potentielles dans le code source des programmes écrits en C, C++, C# et Java. Il fonctionne sur des systÚmes 64 bits sous Windows, Linux et macOS. Il peut analyser du code destiné aux plateformes ARM 32 bits, 64 bits et embarquées.
Au fait, nous avons sorti PVS-Studio 7.08, dans lequel nous avons apporté beaucoup de choses . Par exemple :
- analyseur C# pour Linux et macOS ;
- plugin pour Rider ;
- nouveau mode de vérification de liste de fichiers.
Mode de vérification de liste de fichiers
Auparavant, pour vérifier certains fichiers, il était nécessaire de fournir à l'analyseur un .xml contenant la liste des fichiers. Mais comme cela n'était pas trÚs pratique, nous avons ajouté la possibilité de transmettre un .txt, ce qui simplifie beaucoup la vie.
Pour vérifier certains fichiers, il est nécessaire d'indiquer le flag --sourceFiles (-f) et de fournir un .txt avec la liste des fichiers. Cela se présente comme suit :
pvs-studio-dotnet -t path/to/solution.sln -f fileList.txt -o project.jsonSi vous souhaitez configurer la vérification des commits ou des pull requests, vous pouvez également le faire en utilisant ce mode. La différence résidera dans l'obtention de la liste des fichiers à analyser et dépendra des systÚmes que vous utilisez.
Principe de vérification des demandes de fusion
L'idée principale de la vérification est que les problÚmes détectés par l'analyseur ne se retrouvent pas dans la master branche lors de la fusion. De plus, nous ne souhaitons pas analyser le projet dans son intégralité à chaque fois. D'autant plus que lors de la fusion des branches, nous avons la liste des fichiers modifiés. C'est pourquoi je propose d'ajouter la vérification des demandes de fusion.
Voici à quoi ressemble une demande de fusion avant l'implémentation de l'analyseur statique :

C'est-à -dire que toutes les erreurs qui étaient dans la branche changes, passeront à la branche master. Comme nous ne le souhaitons pas, nous ajoutons une analyse, et maintenant le schéma ressemble à ceci :

Nous analysons changes2 et, s'il n'y a pas d'erreurs, nous acceptons la demande de fusion, sinon nous la rejetons.
Au fait, si vous ĂȘtes intĂ©ressĂ© par l'analyse des commits et des pull requests pour C/C++, vous pouvez lire Ă ce sujet. .
GitLab
â un outil web de cycle de vie DevOps open source, reprĂ©sentant un systĂšme de gestion de dĂ©pĂŽts de code pour Git avec sa propre wiki, un systĂšme de suivi des bugs, un pipeline CI/CD et d'autres fonctionnalitĂ©s.
Avant de commencer Ă mettre en Ćuvre l'analyse des demandes de fusion, il est nĂ©cessaire de s'inscrire et de tĂ©lĂ©charger votre projet. Si vous ne savez pas comment faire, je vous propose de mon collĂšgue.
Remarque. La méthode de configuration de l'environnement décrite ci-dessous est une des possibilités. L'objectif est de montrer les étapes nécessaires à la configuration de l'environnement pour l'analyse et au lancement de l'analyseur. Il est possible que, dans votre cas, il soit plus optimal de séparer les étapes de préparation de l'environnement (ajout de dépÎts, installation de l'analyseur) et d'analyse : par exemple, préparer des images Docker avec l'environnement nécessaire et les utiliser ou une autre méthode.
Pour mieux comprendre ce qui va se passer maintenant, je vous propose de jeter un Ćil au schĂ©ma suivant :

Pour faire fonctionner l'analyseur, le .NET Core SDK 3 est nécessaire, donc avant d'installer l'analyseur, il faut ajouter les dépÎts Microsoft à partir desquels les dépendances nécessaires à l'analyseur seront installées. L'ajout des dépÎts Microsoft pour différentes distributions Linux .
Pour installer PVS-Studio via un gestionnaire de paquets, il faudra également ajouter les dépÎts PVS-Studio. L'ajout des dépÎts pour différentes distributions est décrit plus en détail dans .
L'analyseur nĂ©cessite une clĂ© de licence. Une licence d'essai peut ĂȘtre obtenue sur .
Remarque. Notez que pour le mode de fonctionnement décrit (analyse des demandes de fusion), une licence Enterprise est nécessaire. Donc, si vous souhaitez essayer ce mode de fonctionnement, n'oubliez pas d'indiquer dans le champ "Message" que vous avez besoin d'une licence Enterprise.
S'il y a une demande de fusion, nous devrons analyser uniquement la liste des fichiers modifiés, sinon nous analysons tous les fichiers. AprÚs l'analyse, il faut convertir les journaux dans le format dont nous avons besoin.
Maintenant, avec l'algorithme de fonctionnement sous les yeux, nous pouvons passer Ă l'Ă©criture du script. Pour ce faire, il faut modifier le fichier .gitlab-ci.yml ou, s'il n'existe pas, le crĂ©er. Pour le crĂ©er, cliquez sur le nom de votre projet â Configurer CI/CD.

Nous sommes maintenant prĂȘts Ă Ă©crire le script. Commençons par Ă©crire le code qui installera l'analyseur et saisira la licence :
before_script:
- apt-get update && apt-get -y install wget gnupg
- apt-get -y install git
- wget https://packages.microsoft.com/config/debian/10/
packages-microsoft-prod.deb -O packages-microsoft-prod.deb
- dpkg -i packages-microsoft-prod.deb
- apt-get update
- apt-get install apt-transport-https
- apt-get update
- wget -q -O - https://files.viva64.com/etc/pubkey.txt | apt-key add -
- wget -O /etc/apt/sources.list.d/viva64.list
https://files.viva64.com/etc/viva64.list
- apt-get update
- apt-get -y install pvs-studio-dotnet
- pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY
- dotnet restore "$CI_PROJECT_DIR"/Test/Test.slnĂtant donnĂ© que l'installation et l'activation doivent se produire avant tous les autres scripts, nous utilisons un marqueur spĂ©cial before_script. Permettez-moi d'expliquer ce fragment.
Préparation à l'installation de l'analyseur :
- wget https://packages.microsoft.com/config/debian/10/
packages-microsoft-prod.deb -O packages-microsoft-prod.deb
- dpkg -i packages-microsoft-prod.deb
- apt-get update
- apt-get install apt-transport-https
- apt-get updateAjout des dépÎts PVS-Studio et de l'analyseur :
- wget -q -O - https://files.viva64.com/etc/pubkey.txt | apt-key add -
- wget -O /etc/apt/sources.list.d/viva64.list
https://files.viva64.com/etc/viva64.list
- apt-get update
- apt-get -y install pvs-studio-dotnetActivation de la licence :
- pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY$PVS_NAME â nom d'utilisateur.
$PVS_KEY â clĂ© de produit.
Restauration des dĂ©pendances du projet, oĂč $CI_PROJECT_DIR â chemin complet vers le rĂ©pertoire du projet :
- dotnet restore "$CI_PROJECT_DIR"/Path/To/Solution.slnPour une analyse correcte, le projet doit se compiler avec succĂšs et ses dĂ©pendances doivent ĂȘtre restaurĂ©es (par exemple, les packages NuGet nĂ©cessaires doivent ĂȘtre tĂ©lĂ©chargĂ©s).
Les variables d'environnement contenant les informations de licence peuvent ĂȘtre dĂ©finies en cliquant sur Configuration, puis sur CI / CD.

Dans la fenĂȘtre qui s'ouvre, nous trouvons le point Variables, puis Ă droite, nous cliquons sur le bouton DĂ©velopper et ajoutons les variables. Le rĂ©sultat doit ĂȘtre le suivant :

Nous pouvons maintenant passer Ă l'analyse. Commençons par ajouter le script pour une analyse complĂšte. Dans le drapeau -t nous passons le chemin vers la solution, dans le drapeau -o nous Ă©crivons le chemin vers le fichier dans lequel les rĂ©sultats de l'analyse seront enregistrĂ©s. Nous nous intĂ©ressons Ă©galement au code de retour. Dans ce cas, nous voulons que l'exĂ©cution s'arrĂȘte lorsque le code de retour indique qu'il y a eu des avertissements lors de l'analyse. Voici Ă quoi ressemble ce fragment :
job:
script:
- exit_code=0
- pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -o
PVS-Studio.json || exit_code=$?
- exit_code=$((($exit_code & 8)/8))
- if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fiLes codes de retour fonctionnent sur le principe du masquage de bits. Par exemple, si des avertissements ont Ă©tĂ© Ă©mis lors de l'analyse, le code de retour sera Ă©gal Ă 8. Si la licence expire dans un mois, le code de retour sera Ă©gal Ă 4. Si des erreurs ont Ă©tĂ© dĂ©tectĂ©es lors de l'analyse et que la licence expire Ă©galement dans un mois, les deux valeurs seront enregistrĂ©es dans le code de retour : nous additionnons les nombres et obtenons le code de retour final â 8+4=12. Ainsi, en vĂ©rifiant les bits correspondants, on peut obtenir des informations sur diffĂ©rents Ă©tats lors de l'analyse. Les codes de retour sont dĂ©crits plus en dĂ©tail dans la section "Codes de retour pvs-studio-dotnet (Linux / macOS)" du document.".
Dans ce cas, nous nous intĂ©ressons Ă tous les codes de retour oĂč figure le 8.
- exit_code=$((($exit_code & 8) / 8))Nous obtiendrons 1 lorsque le code de retour contient le bit qui nous intéresse, sinon nous obtiendrons 0.
Il est temps d'ajouter l'analyse des demandes de fusion. Avant de le faire, préparons l'espace pour le script. Nous avons besoin qu'il ne s'exécute que lorsque des demandes de fusion ont lieu. Cela se présente comme suit :
merge:
script:
only:
- merge_requestsPassons maintenant au script. J'ai constaté que la machine virtuelle ne sait rien sur origin/master. Par conséquent, nous l'aidons un peu :
- git fetch originNous allons maintenant obtenir la différence entre les branches et enregistrer le résultat dans txt fichier :
- git diff --name-only origin/master $CI_COMMIT_SHA > pvs-fl.txtOĂč $CI_COMMIT_SHA â le hachage du dernier commit.
Ensuite, nous exécutons l'analyse de la liste des fichiers en utilisant le drapeau -f. Nous lui passons le fichier .txt obtenu précédemment. Et de maniÚre similaire à l'analyse complÚte, nous observons les codes de retour :
- exit_code=0
- pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -f
pvs-fl.txt -o PVS-Studio.json || exit_code=$?
- exit_code=$((($exit_code & 8) / 8))
- if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fiLe script complet pour vérifier les demandes de fusion ressemblera à ceci :
merge:
script:
- git fetch origin
- git diff --name-only origin/master $CI_COMMIT_SHA > pvs-fl.txt
- exit_code=0
- pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -f
pvs-fl.txt -o PVS-Studio.json || exit_code=$?
- exit_code=$((($exit_code & 8) / 8))
- if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi
only:
- merge_requestsIl ne reste plus qu'à ajouter la conversion du journal aprÚs que tous les scripts ont été exécutés. Utilisons l'étiquette after_script et l'outil plog-converter:
after_script:
- plog-converter -t html -o eLog ./PVS-Studio.jsonUtilitaire â est un projet open source utilisĂ© pour convertir des rapports d'erreurs de l'analyseur en diffĂ©rents formats, comme HTML. Une description plus dĂ©taillĂ©e de l'outil se trouve dans la section "Utilitaire Plog Converter" .
Au fait, si vous souhaitez travailler confortablement avec le rapport .json localement depuis votre IDE, je propose notre pour l'IDE Rider. Son utilisation est décrite plus en détail dans .
Pour votre commodité, voici .gitlab-ci.yml en entier :
image: debian
before_script:
- apt-get update && apt-get -y install wget gnupg
- apt-get -y install git
- wget https://packages.microsoft.com/config/debian/10/
packages-microsoft-prod.deb -O packages-microsoft-prod.deb
- dpkg -i packages-microsoft-prod.deb
- apt-get update
- apt-get install apt-transport-https
- apt-get update
- wget -q -O - https://files.viva64.com/etc/pubkey.txt | apt-key add -
- wget -O /etc/apt/sources.list.d/viva64.list
https://files.viva64.com/etc/viva64.list
- apt-get update
- apt-get -y install pvs-studio-dotnet
- pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY
- dotnet restore "$CI_PROJECT_DIR"/Test/Test.sln
merge:
script:
- git fetch origin
- git diff --name-only origin/master $CI_COMMIT_SHA > pvs-fl.txt
- exit_code=0
- pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -f
pvs-fl.txt -o PVS-Studio.json || exit_code=$?
- exit_code=$((($exit_code & 8)/8))
- if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi
only:
- merge_requests
job:
script:
- exit_code=0
- pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -o
PVS-Studio.json || exit_code=$?
- exit_code=$((($exit_code & 8)/8))
- if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi
after_script:
- plog-converter -t html -o eLog ./PVS-Studio.jsonUne fois que vous avez tout ajoutĂ© au fichier, cliquez sur Commit changes. Pour vĂ©rifier que tout est correct, allez dans CI/CD -> Pipelines -> Running. Une fenĂȘtre de machine virtuelle s'ouvrira, Ă la fin de laquelle il devrait y avoir :

Nous avons vu Job succeeded â succĂšs, tout est parfait. Maintenant, vous pouvez tester ce que vous avez fait.
Exemples de travail
Pour l'exemple de travail, créons un projet simple (dans master) qui contiendra plusieurs fichiers. Ensuite, dans une autre branche, modifions seulement un fichier et essayons de faire une demande de fusion.
Considérons deux cas : lorsque le fichier modifié contient une erreur et lorsque ce n'est pas le cas. Commençons par l'exemple avec une erreur.
Supposons que dans la branche master, il y a un fichier Program.cs, qui ne contient pas d'erreurs, tandis que dans une autre branche, le développeur a ajouté un code erroné et souhaite faire une demande de fusion. Quelle erreur il a commise n'est pas si important, l'essentiel est qu'elle existe. Par exemple, il a oublié l'opérateur throw (oui, ):
void MyAwesomeMethod(String name)
{
if (name == null)
new ArgumentNullException(....);
// faites quelque chose
....
}Regardons le résultat de l'analyse de l'exemple avec une erreur. Aussi, pour m'assurer que seul un fichier a été analysé, j'ai ajouté un drapeau -r à la ligne de commande de pvs-studio-dotnet :

Nous voyons que l'analyseur a trouvĂ© l'erreur et a empĂȘchĂ© la fusion des branches.
Vérifions l'exemple sans erreur. Corrigeons le code :
void MyAwesomeMethod(String name)
{
if (name == null)
throw new ArgumentNullException(....);
// faites quelque chose
....
}Résultats de l'analyse de la demande de fusion :

Comme nous le voyons, aucune erreur n'a été trouvée, et l'exécution de la tùche a réussi, ce que nous voulions vérifier.
Conclusion
Ăliminer le mauvais code avant la fusion des branches est trĂšs pratique et agrĂ©able. Par consĂ©quent, si vous utilisez CI/CD, essayez d'intĂ©grer un analyseur statique pour les vĂ©rifications. D'autant plus que cela se fait assez facilement.
Merci pour votre attention.
Si vous souhaitez partager cet article avec un public anglophone, veuillez utiliser le lien vers la traduction : Nikolay Mironov. .
Source : habr.com
