Clever Geek Handbook

Analyse von Zusammenführungsanforderungen in GitLab mit PVS-Studio für C #

image1.png


Lieben Sie GitLab und mögen Sie keine Bugs? Möchten Sie die Qualität Ihres Quellcodes verbessern? Dann sind Sie bei uns genau richtig. Heute erfahren Sie, wie Sie den PVS-Studio C # -Analysator einrichten, um Zusammenführungsanforderungen zu überprüfen. Alle Einhorn Stimmung und angenehmes Lesen.



PVS-Studio ist ein Tool zum Erkennen von Fehlern und potenziellen Schwachstellen im Quellcode von Programmen, die in C, C ++, C # und Java geschrieben wurden. Funktioniert in 64-Bit-Systemen unter Windows, Linux und MacOS. Kann Code für 32-Bit-, 64-Bit- und eingebettete ARM-Plattformen analysieren.



Übrigens haben wir PVS-Studio 7.08 veröffentlicht, in dem wir viele interessante Dinge getan haben . Zum Beispiel:



  • C # -Analysator für Linux und MacOS;
  • Plugin für Rider;
  • neuer Modus zum Überprüfen der Liste der Dateien.


Überprüfungsmodus für Dateilisten



Bisher war es zum Überprüfen bestimmter Dateien erforderlich, eine XML-Datei mit einer Liste von Dateien an den Parser zu übergeben. Da dies jedoch nicht sehr praktisch ist, haben wir die Möglichkeit hinzugefügt, .txt zu übertragen, was das Leben sehr einfach macht.



Um bestimmte Dateien zu überprüfen, müssen Sie das Flag --sourceFiles ( -f ) angeben und .txt mit einer Liste von Dateien übergeben. Es sieht aus wie das: 



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


Wenn Sie die Überprüfung auf Commits oder Pull-Anforderungen konfigurieren möchten, können Sie dies auch in diesem Modus tun. Der Unterschied besteht darin, eine Liste der zu analysierenden Dateien zu erhalten, und hängt davon ab, welche Systeme Sie verwenden.



Prinzip zur Überprüfung der Zusammenführungsanforderung



Der Hauptpunkt der Überprüfung ist , dass die durch den Analysator festgestellten Probleme nicht in dem am Ende Master Zweig während der Zusammenführung . Außerdem möchten wir nicht jedes Mal das gesamte Projekt analysieren. Darüber hinaus haben wir beim Zusammenführen von Zweigen eine Liste der geänderten Dateien. Daher schlage ich vor, einen Scheck für die Zusammenführungsanforderung hinzuzufügen.



So sieht eine Zusammenführungsanforderung aus, bevor ein statischer Analysator implementiert wird:



image2.png


Das heißt, alle Fehler, die im Änderungszweig aufgetreten sind, werden in den Hauptzweig verschoben. Da uns das nicht gefallen würde, fügen wir eine Analyse hinzu, und jetzt sieht das Diagramm folgendermaßen aus:



image3.png


Wir analysieren Änderungen2 und akzeptieren , wenn keine Fehler vorliegen , die Zusammenführungsanforderung, andernfalls lehnen wir sie ab.



Übrigens, wenn Sie daran interessiert sind, Commits zu analysieren und Anforderungen für C / C ++ abzurufen, können Sie hier darüber lesen .



Gitlab



GitLab ist ein webbasiertes Open-Source-Tool für den DevOps-Lebenszyklus, das ein Code-Repository-Verwaltungssystem für Git mit eigenem Wiki, Bug-Tracker, CI / CD-Pipeline und mehr bietet.



Bevor Sie mit der Implementierung der Analyse von Zusammenführungsanforderungen beginnen, müssen Sie sich registrieren und Ihr Projekt hochladen. Wenn Sie nicht wissen, wie das geht, schlage ich einen Artikel meines Kollegen vor.



Hinweis... Die unten beschriebene Umgebungseinstellungsmethode ist eine der möglichen. Ziel ist es, die Schritte zum Einrichten der für die Analyse erforderlichen Umgebung und zum Ausführen des Analysators aufzuzeigen. In Ihrem Fall ist es möglicherweise optimaler, die Phasen der Vorbereitung der Umgebung (Hinzufügen von Repositorys, Installieren eines Analysators) und der Analyse zu trennen: Zum Beispiel das Vorbereiten von Docker-Bildern mit der erforderlichen Umgebung und deren Verwendung oder eine andere Methode.



Um besser zu verstehen, was jetzt passieren wird, schlage ich vor, das folgende Diagramm zu betrachten:



image4.png


Für den Analysator ist .NET Core SDK 3 erforderlich. Vor der Installation des Analysators müssen Sie daher die Microsoft-Repositorys hinzufügen, von denen die für den Analysator erforderlichen Abhängigkeiten installiert werden. Das Hinzufügen von Microsoft-Repositorys für verschiedene Linux-Distributionen wird im entsprechenden Dokument beschrieben .



Um PVS-Studio über den Paketmanager zu installieren, müssen Sie auch PVS-Studio-Repositorys hinzufügen. Das Hinzufügen von Repositorys für verschiedene Distributionen wird im entsprechenden Abschnitt der Dokumentation ausführlicher beschrieben .



Der Analysator benötigt zum Betrieb einen Lizenzschlüssel. Eine Testlizenz erhalten Sie auf der Download-Seite des Analysators .



Hinweis... Bitte beachten Sie, dass für den beschriebenen Betriebsmodus (Analyse von Zusammenführungsanforderungen) eine Unternehmenslizenz erforderlich ist. Wenn Sie diesen Betriebsmodus ausprobieren möchten, vergessen Sie daher nicht, im Feld "Nachricht" anzugeben, dass Sie die Enterprise-Lizenz benötigen.



Wenn eine Zusammenführungsanforderung auftritt, müssen wir nur die Liste der geänderten Dateien analysieren, andernfalls analysieren wir alle Dateien. Nach der Analyse müssen wir die Protokolle in das gewünschte Format konvertieren.



Nachdem Sie nun den Algorithmus der Arbeit vor Augen haben, können Sie mit dem Schreiben eines Skripts fortfahren. Dazu müssen Sie die Datei .gitlab-ci.yml ändern oder, falls nicht, erstellen. Um es zu erstellen, müssen Sie auf den Namen Ihres Projekts klicken -> CI / CD einrichten .



image5.png


Jetzt können wir das Skript schreiben. Schreiben wir zunächst den Code, mit dem der Analysator installiert wird, und geben die Lizenz ein: 



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


Da die Installation und Aktivierung vor allen anderen Skripten erfolgen muss, verwenden wir ein spezielles before_script- Tag . Ich werde dieses Fragment ein wenig erklären.



Vorbereiten der Installation des Analysators: 



  - 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


Hinzufügen von PVS-Studio-Repositorys und -Analysatoren: 



  - 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


Lizenzaktivierung: 



  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY


$ PVS_NAME - Benutzername.



$ PVS_KEY - Produktschlüssel.



Wiederherstellen von Projektabhängigkeiten, wobei $ CI_PROJECT_DIR der vollständige Pfad zum Projektverzeichnis ist: 



  - dotnet restore "$CI_PROJECT_DIR"/Path/To/Solution.sln


Für eine korrekte Analyse muss das Projekt erfolgreich erstellt und seine Abhängigkeiten wiederhergestellt werden (z. B. müssen die erforderlichen NuGet-Pakete geladen werden).



Sie können Umgebungsvariablen mit Lizenzinformationen festlegen, indem Sie auf Einstellungen und dann auf CI / CD klicken .



image6.png


In dem sich öffnenden Fenster finden Sie den Variablen Element auf der rechten Seite , klicken Sie auf die Expand - Taste und fügen Sie Variablen. Das Ergebnis sollte folgendermaßen aussehen:



image7.png


Jetzt können Sie mit der Analyse fortfahren. Fügen wir zunächst ein Skript für die vollständige Analyse hinzu. Das Flag -t Übertragungspfad zur Lösung, ein Flag -o Schreibort der Datei, in der die Analyseergebnisse aufgezeichnet werden. Wir sind auch am Rückkehrcode interessiert. In diesem Fall sind wir daran interessiert, die Arbeit zu beenden, wenn der Rückkehrcode Informationen enthält, dass während der Analyse Warnungen ausgegeben wurden. So sieht dieses Snippet aus: 



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


Rückkehrcodes funktionieren wie eine Bitmaske. Wenn beispielsweise als Ergebnis der Analyse Warnungen ausgegeben wurden, lautet der Rückkehrcode 8. Wenn die Lizenz innerhalb eines Monats abläuft, lautet der Rückkehrcode 4. Wenn während der Analyse Fehler gefunden wurden und die Lizenz innerhalb eines Monats im Code abläuft return, beide Werte werden geschrieben: Addiere die Zahlen und erhalte den endgültigen Rückkehrcode - 8 + 4 = 12. Durch Überprüfen der entsprechenden Bits können somit Informationen über verschiedene Zustände während der Analyse erhalten werden. Die Rückkehrcodes werden ausführlicher im Abschnitt "Rückkehrcodes von pvs-studio-dotnet (Linux / macOS)" des Dokuments " Überprüfen von Visual Studio / MSBuild / .NET Core-Projekten über die Befehlszeile mit PVS-Studio " beschrieben.



In diesem Fall sind wir an allen Rückkehrcodes interessiert,wo 8 erscheint. 



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


Wir erhalten 1, wenn der Rückkehrcode das Bit der Nummer enthält, an der wir interessiert sind, andernfalls erhalten wir 0.



Es ist Zeit, die Analyse der Zusammenführungsanforderung hinzuzufügen. Bevor wir dies tun, bereiten wir einen Platz für das Skript vor. Wir brauchen es nur, um es auszuführen, wenn eine Zusammenführungsanforderung auftritt. Es sieht aus wie das: 



merge:
  script:
  only:
  - merge_requests


Fahren wir mit dem Skript selbst fort. Ich bin auf die Tatsache gestoßen, dass die virtuelle Maschine nichts über Ursprung / Master weiß . Deshalb helfen wir ihr ein wenig: 



  - git fetch origin


Lassen Sie uns nun den Unterschied zwischen den Zweigen ermitteln und das Ergebnis in einer txt- Datei speichern: 



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


Wobei $ CI_COMMIT_SHA der Hash des letzten Commits ist.



Als nächstes führen wir die Analyse der Liste der Dateien mit dem Flag -f aus . Wir übertragen die zuvor empfangene TXT-Datei darauf. In Analogie zur vollständigen Analyse betrachten wir die Rückkehrcodes: 



  - 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


Das vollständige Skript zum Überprüfen der Zusammenführungsanforderung sieht folgendermaßen aus: 



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


Die Konvertierung des Protokolls muss erst hinzugefügt werden, nachdem alle Skripts ausgeführt wurden. Wir verwenden das Label after_script und das Dienstprogramm plog-converter : 



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


Das Dienstprogramm plog-converter ist ein Open-Source-Projekt, mit dem der Analysefehlerbericht in verschiedene Formen wie HTML konvertiert wird. Eine detailliertere Beschreibung des Dienstprogramms finden Sie im Unterabschnitt "Plog Converter Utility" des entsprechenden Abschnitts der Dokumentation .



Übrigens, wenn Sie bequem mit dem .json-Bericht lokal von der IDE aus arbeiten möchten, dann schlage ich unser Plugin für den IDE-Fahrer vor. Ihre Verwendung wird im entsprechenden Dokument näher beschrieben .



Hier ist der Einfachheit halber die gesamte .gitlab-ci.yml : 



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


Wenn alles zur Datei hinzugefügt wurde, klicken Sie auf Änderungen übernehmen . Um zu sehen, ob alles korrekt ist, gehen Sie zu CI / CD -> Pipelines -> Running . Ein Fenster für eine virtuelle Maschine wird geöffnet, an dessen Ende Folgendes angezeigt werden sollte:



image8.png


Wir haben gesehen, dass Job erfolgreich war - Erfolg, alles ist in Ordnung. Jetzt können Sie testen, was Sie getan haben.



Beispiele für Arbeiten



Als Beispiel für eine Arbeit erstellen wir ein einfaches Projekt (im Master ), in dem sich mehrere Dateien befinden. Danach ändern wir in einem anderen Zweig nur eine Datei und versuchen, eine Zusammenführungsanforderung zu stellen.



Betrachten Sie zwei Fälle: Wenn die geänderte Datei einen Fehler enthält und wenn nicht. Zunächst ein Beispiel mit einem Fehler.



Angenommen, es gibt eine Program.cs- Datei im Hauptzweig , die keine Fehler enthält, und in einem anderen Zweig hat der Entwickler fehlerhaften Code hinzugefügt und möchte eine Zusammenführungsanforderung stellen. Welche Art von Fehler er gemacht hat, ist nicht so wichtig, die Hauptsache ist, dass es ihn gibt. Zum Beispiel habe ich den Wurfoperator vergessen (ja, sie sind so falsch ): 



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


Schauen wir uns das Ergebnis der Analyse eines Beispiels mit einem Fehler an. Um sicherzustellen, dass nur eine Datei analysiert wurde, habe ich der Startzeile von pvs-studio-dotnet das Flag -r hinzugefügt :



image9.png


Wir sehen, dass der Analysator einen Fehler gefunden hat und das Zusammenführen von Zweigen nicht zugelassen hat.



Überprüfen Sie das Beispiel ohne Fehler. Wir korrigieren den Code: 



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


Ergebnisse der Analyse der Zusammenführungsanforderung:



image10.png


Wie wir sehen können, wurden keine Fehler gefunden und die Ausführung der Aufgabe war erfolgreich, was wir überprüfen wollten.



Fazit



Das Herausfiltern von fehlerhaftem Code vor dem Zusammenführen von Zweigen ist sehr bequem und macht Spaß. Wenn Sie CI / CD verwenden, versuchen Sie daher, einen statischen Analysator zum Testen einzubauen. Darüber hinaus geschieht dies ganz einfach.



Vielen Dank für Ihre Aufmerksamkeit.





Wenn Sie diesen Artikel einem englischsprachigen Publikum zugänglich machen möchten, verwenden Sie bitte den Übersetzungslink: Nikolay Mironov. Analyse von Zusammenführungsanforderungen in GitLab mit PVS-Studio für C # .


More articles:


All Articles