🥇Analyse des demandes de fusion dans GitLab à l'aide de PVS-Studio pour C#

Vous aimez GitLab et détestez les bugs ? Vous souhaitez améliorer la qualité de votre code source ? Alors vous êtes au bon endroit. Aujourd'hui, nous allons vous expliquer comment configurer l'analyseur PVS-Studio C# pour vérifier les demandes de fusion. Bonne humeur licorne et bonne lecture à tous.

PVS-Studio est un outil permettant d'identifier les erreurs et les vulnérabilités potentielles dans le code source des programmes écrits en C, C++, C# et Java. Fonctionne sur les systèmes 64 bits sous Windows, Linux et macOS. Peut analyser le code conçu pour les plates-formes 32 bits, 64 bits et ARM intégrées.

À propos, nous avons sorti PVS-Studio 7.08, dans lequel nous avons fait beaucoup de choses intéressant. Par exemple:

Analyseur C# pour Linux et macOS ;
plug-in pour Rider ;
nouveau mode de vérification de la liste de fichiers.

Mode de vérification de la liste de fichiers

Auparavant, pour vérifier certains fichiers, il fallait transmettre un .xml avec une liste de fichiers à l'analyseur. Mais comme ce n'est pas très pratique, nous avons ajouté la possibilité de transférer des .txt, ce qui rend la vie très simple.

Afin de vérifier des fichiers spécifiques, vous devez spécifier le drapeau --fichiers source (-f) et transférez le .txt avec une liste de fichiers. Cela ressemble à ceci :

pvs-studio-dotnet -t path/to/solution.sln -f fileList.txt -o project.json

Si vous souhaitez configurer une vérification de validation ou des demandes d'extraction, vous pouvez également le faire en utilisant ce mode. La différence résidera dans l'obtention d'une liste de fichiers à analyser et dépendra des systèmes que vous utilisez.

Le principe de vérification d'une demande de fusion

L'essence principale du contrôle est de s'assurer que les problèmes détectés par l'analyseur lors de la fusion ne tombent pas dans le maître bifurquer. Nous ne voulons pas non plus analyser l’intégralité du projet à chaque fois. De plus, lors de la fusion de branches, nous avons une liste des fichiers modifiés. Par conséquent, je suggère d'ajouter une vérification de demande de fusion.

Voici à quoi ressemble une demande de fusion avant d'implémenter un analyseur statique :

Autrement dit, toutes les erreurs qui se trouvaient dans la branche change, sera déplacé vers la branche master. Puisque nous ne voudrions pas cela, nous ajoutons une analyse, et maintenant le diagramme ressemble à ceci :

en cours d'analyse changements2 et, s'il n'y a pas d'erreurs, nous acceptons la demande de fusion, sinon nous la rejetons.

À propos, si vous souhaitez analyser les commits et les pull request pour C/C++, vous pouvez en savoir plus ici.

gitlab ce

gitlab ce est un outil de cycle de vie DevOps open source basé sur le Web qui fournit un système de gestion de référentiel de code pour Git avec son propre wiki, un système de suivi des problèmes, un pipeline CI/CD et d'autres fonctionnalités.

Avant de commencer à analyser les demandes de fusion, vous devez vous inscrire et télécharger votre projet. Si vous ne savez pas comment faire, je vous suggère статью Mon collègue.

Noter. La méthode de mise en place de l’environnement décrite ci-dessous fait partie des possibles. Le but est de montrer les étapes de mise en place de l'environnement nécessaire à l'analyse et au lancement de l'analyseur. Peut-être que dans votre cas, il serait plus optimal de séparer les étapes de préparation de l'environnement (ajout de référentiels, installation d'un 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 suggère de regarder le schéma suivant :

L'analyseur nécessite .NET Core SDK 3 pour fonctionner, donc avant d'installer l'analyseur, vous devez ajouter les référentiels Microsoft à partir desquels les dépendances requises pour l'analyseur seront installées. Ajout de référentiels Microsoft pour diverses distributions Linux décrit dans le document correspondant.

Pour installer PVS-Studio via le gestionnaire de packages, vous devrez également ajouter les référentiels PVS-Studio. L'ajout de référentiels pour différentes distributions est décrit plus en détail dans section pertinente de la documentation.

L'analyseur nécessite une clé de licence pour fonctionner. Vous pouvez obtenir une licence d'essai sur page de téléchargement de l'analyseur.

Noter. Attention, le mode de fonctionnement décrit (analyse des demandes de fusion) nécessite une licence Entreprise. Par conséquent, si vous souhaitez essayer ce mode de fonctionnement, n'oubliez pas d'indiquer dans le champ « Message » que vous avez besoin d'une licence Entreprise.

Si une demande de fusion se produit, il suffit alors d'analyser la liste des fichiers modifiés, sinon nous analysons tous les fichiers. Après analyse, nous devons convertir les journaux dans le format dont nous avons besoin.

Maintenant, ayant l'algorithme de travail sous les yeux, vous pouvez passer à l'écriture d'un script. Pour ce faire, vous devez modifier le fichier .gitlab-ci.yml ou, s'il n'existe pas, créez-le. Pour le créer, vous devez cliquer sur le nom de votre projet -> Configurer CI/CD.

Nous sommes maintenant prêts à écrire le scénario. Écrivons d'abord le code qui installera l'analyseur et saisissons 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

Puisque l'installation et l'activation doivent avoir lieu avant tous les autres scripts, nous utilisons une étiquette spéciale avant_script. Permettez-moi d'expliquer un peu ce fragment.

Préparation de 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 update

Ajout des référentiels 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-dotnet

Activation de la licence :

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME - Nom d'utilisateur.

$PVS_KEY - clé de produit.

Récupération 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.sln

Pour une analyse correcte, le projet doit être construit avec succès et ses dépendances doivent être restaurées (par exemple, les packages NuGet nécessaires doivent être téléchargés).

Vous pouvez définir des variables d'environnement contenant des informations de licence en cliquant sur Paramètres, et après - sur CI/CD.

Dans la fenêtre qui s'ouvre, recherchez l'élément Variables, cliquez sur le bouton à droite Développer vous et ajoutez des variables. Le résultat devrait ressembler à ceci :

Vous pouvez maintenant passer à l'analyse. Tout d’abord, ajoutons un script pour une analyse complète. Au drapeau -t nous passons le chemin vers la solution au drapeau -o écrivez le chemin d'accès au fichier dans lequel les résultats de l'analyse seront écrits. Nous sommes également intéressés par le code retour. Dans ce cas, nous nous intéressons à l'arrêt de l'opération lorsque le code retour contient des informations indiquant que des avertissements ont été émis 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; fi

Les codes retour fonctionnent sur le principe d'un masque de bits. Par exemple, si des avertissements ont été émis à la suite de l'analyse, alors le code retour sera égal à 8. Si la licence expire dans un délai d'un mois, alors le code retour sera égal à 4. Si des erreurs ont été détectées lors de l'analyse, et la licence expire dans un mois, le code revient, les deux valeurs seront écrites : additionnez les nombres ensemble et obtenez le code retour final - 8+4=12. Ainsi, en vérifiant les bits correspondants, des informations sur différents états peuvent être obtenues lors de l'analyse. Les codes retour sont décrits plus en détail dans la section "Codes retour pvs-studio-dotnet (Linux / macOS)" du document "Vérification des projets Visual Studio / MSBuild / .NET Core à partir de la ligne de commande à l'aide de PVS-Studio".

Dans ce cas, nous nous intéressons à tous les codes retour où apparaît 8.

  - exit_code=$((($exit_code & 8)/8))

Nous recevrons 1 lorsque le code retour contient le bit du nombre qui nous intéresse, sinon nous recevrons 0.

Il est temps d'ajouter l'analyse des demandes de fusion. Avant de faire cela, préparons une place pour le script. Nous avons besoin qu'il soit exécuté uniquement lorsqu'une demande de fusion se produit. Cela ressemble à ceci :

merge:
  script:
  only:
  - merge_requests

Passons au script lui-même. J'ai été confronté au fait que la machine virtuelle ne sait rien de origine / maître. Alors aidons-la un peu :

  - git fetch origin

Maintenant, nous obtenons la différence entre les branches et enregistrons le résultat dans txt déposer:

  - git diff --name-only origin/master $CI_COMMIT_SHA > pvs-fl.txt

Où $CI_COMMIT_SHA – hachage du dernier commit.

Ensuite, nous commençons à analyser la liste des fichiers à l'aide du drapeau -f. Nous y transférons le fichier .txt précédemment reçu. Eh bien, par analogie avec l'analyse complète, nous regardons les codes 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; fi

Le script complet de vérification d'une demande 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_requests

Il ne reste plus qu'à ajouter la conversion du journal une fois que tous les scripts ont été traités. Nous utilisons l'étiquette après_script et utilité plog-convertisseur:

after_script:
  - plog-converter -t html -o eLog ./PVS-Studio.json

Utilitaire plog-convertisseur est un projet open source utilisé pour convertir les rapports d'erreurs de l'analyseur sous diverses formes, telles que HTML. Une description plus détaillée de l'utilitaire est donnée dans la sous-section « Utilitaire Plog Converter » section pertinente de la documentation.

À propos, si vous souhaitez travailler facilement avec les rapports .json localement à partir de l'EDI, je suggère notre Plugin pour IDE Rider. Son utilisation est décrite plus en détail dans document pertinent.

Pour plus de commodité, le 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.json

Une fois que vous avez tout ajouté au fichier, cliquez sur Valider les modifications. Pour vérifier que tout est correct, allez sur CI / CD -> Pipelines -> Fonctionnement. Une fenêtre de machine virtuelle s'ouvrira, à la fin de laquelle il devrait y avoir ce qui suit :

scie Travail réussi - succès, tout va bien. Vous pouvez maintenant tester ce que vous avez fait.

Exemples de travail

Pour un exemple de travail, créons un projet simple (en maître) qui contiendra plusieurs fichiers. Après cela, dans une autre branche, nous ne modifierons qu'un seul fichier et essaierons de faire une demande de fusion.

Considérons deux cas : lorsque le fichier modifié contient une erreur et lorsqu'il n'en contient pas. Tout d'abord, un exemple avec une erreur.

Disons qu'il y a un fichier dans la branche master programme.cs, qui ne contient pas d'erreurs, mais dans une autre branche, le développeur a ajouté du code erroné et souhaite faire une demande de fusion. Le genre d'erreur qu'il a commis n'est pas si important, l'essentiel est qu'elle existe. Par exemple, l'opérateur a oublié renversement (Oui, tellement faux):

void MyAwesomeMethod(String name)
{
  if (name == null)
    new ArgumentNullException(....);
  // do something
  ....
}

Regardons le résultat de l'analyse d'un exemple avec une erreur. Aussi pour m'assurer qu'un seul fichier a été analysé, j'ai ajouté le drapeau -r à la ligne de lancement pvs-studio-dotnet :

Nous voyons que l'analyseur a trouvé une erreur et n'a pas permis la fusion des branches.

Vérifions l'exemple sans erreur. Correction du code :

void MyAwesomeMethod(String name)
{
  if (name == null)
    throw new ArgumentNullException(....);
  // do something
  ....
}

Résultats de l'analyse des demandes de fusion :

Comme nous pouvons le constater, 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 de fusionner les branches est très pratique et agréable. Donc, si vous utilisez CI/CD, essayez d'intégrer un analyseur statique pour vérifier. De plus, cela se fait tout simplement.

Je vous remercie de votre attention.

Si vous souhaitez partager cet article avec un public anglophone, veuillez utiliser le lien de traduction : Nikolay Mironov. Analyse des demandes de fusion dans GitLab à l'aide de PVS-Studio pour C#.

Source: habr.com

Analyse des demandes de fusion dans GitLab à l'aide de PVS-Studio pour C#

Mode de vérification de la liste de fichiers

Le principe de vérification d'une demande de fusion

gitlab ce

Exemples de travail

Conclusion

Ajouter un commentaire Annuler la réponse