Analyse von Merge-Anfragen in GitLab mit PVS-Studio für C#

Sie lieben GitLab und hassen Bugs? Möchten Sie die Qualität Ihres Quellcodes verbessern? Dann sind Sie bei uns genau richtig. Heute erklären wir Ihnen, wie Sie den PVS-Studio C#-Analysator konfigurieren, um Zusammenführungsanforderungen zu prüfen. Viele Grüße an alle und viel Spaß beim Lesen.

PVS Studio ist ein Tool zur Erkennung von Fehlern und potenziellen Schwachstellen im Quellcode von Programmen, die in C, C++, C# und Java geschrieben sind. Funktioniert auf 64-Bit-Systemen unter Windows, Linux und macOS. Kann Code analysieren, der für 32-Bit-, 64-Bit- und eingebettete ARM-Plattformen entwickelt wurde.

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

• C#-Analysator für Linux und macOS;
• Plugin für Rider;
• Neuer Dateilisten-Prüfmodus.

Dateilisten-Überprüfungsmodus

Um bestimmte Dateien zu überprüfen, war es bisher notwendig, 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 erheblich vereinfacht.

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

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

Wenn Sie Commit-Prüfungen oder Pull-Requests einrichten möchten, können Sie dies auch in diesem Modus tun. Der Unterschied besteht darin, dass Sie eine Liste der zu analysierenden Dateien erhalten, und hängt davon ab, welche Systeme Sie verwenden.

Prinzip der Zusammenführungsanforderungsprüfung

Der Hauptzweck der Prüfung besteht darin, sicherzustellen, dass die vom Analysator erkannten Probleme nicht in die Zusammenführung fallen Master Zweig. 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, eine Überprüfung der Zusammenführungsanfrage hinzuzufügen.

So sieht die Zusammenführungsanforderung vor der Einführung des statischen Analysators aus:

Das heißt, alle Fehler, die in der Filiale aufgetreten sind Änderungen, wird in den Hauptzweig verschoben. Da wir das nicht wollen, fügen wir die Analyse hinzu und nun sieht die Schaltung so aus:

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

Übrigens, wenn Sie sich für die Analyse von Commits und Pull Requests für C/C++ interessieren, dann können Sie sich darüber informieren. hier.

Gitlab

Gitlab ist ein Open-Source-Webtool für den DevOps-Lebenszyklus, das ein Code-Repository-Verwaltungssystem für Git mit eigenem Wiki, Fehlerverfolgungssystem, CI/CD-Pipeline und anderen Funktionen bereitstellt.

Bevor Sie mit der Implementierung der Analyse von Zusammenführungsanfragen fortfahren, müssen Sie Ihr Projekt registrieren und hochladen. Wenn Sie nicht wissen, wie das geht, dann schlage ich vor Artikel mein Kollege.

Beachten. Die unten beschriebene Art und Weise, die Umgebung einzurichten, ist eine der möglichen. Ziel ist es, die Schritte zum Einrichten der für die Analyse erforderlichen Umgebung und zum Starten des Analysegeräts aufzuzeigen. Vielleicht wäre es in Ihrem Fall optimaler, die Phasen der Umgebungsvorbereitung (Hinzufügen von Repositorys, Installieren des Analysators) und der Analyse zu trennen: zum Beispiel das Vorbereiten von Docker-Images mit der erforderlichen Umgebung und deren Verwendung oder auf andere Weise.

Um besser zu verstehen, was jetzt passieren wird, empfehle ich einen Blick auf das folgende Diagramm:

Damit der Analysator funktioniert, ist das .NET Core SDK 3 erforderlich. Daher müssen Sie vor der Installation des Analysators die Microsoft-Repositorys hinzufügen, aus denen die für den Analysator erforderlichen Abhängigkeiten installiert werden. Hinzufügen von Microsoft-Repositorys für verschiedene Linux-Distributionen im entsprechenden Dokument beschrieben.

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

Der Analysator benötigt einen Lizenzschlüssel, um zu funktionieren. Eine Testlizenz erhalten Sie unter Download-Seite für den Analysator.

Beachten. Bitte beachten Sie, dass für die beschriebene Funktionsweise (Analyse von Merge-Requests) eine Enterprise-Lizenz erforderlich ist. Wenn Sie diese Betriebsart ausprobieren möchten, vergessen Sie daher nicht, im Feld „Nachricht“ anzugeben, dass Sie eine 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 benötigte Format konvertieren.

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

Jetzt sind wir bereit, das Skript zu schreiben. Schreiben wir zunächst den Code, der den Analysator installiert und die Lizenz eingibt:

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 eine spezielle Bezeichnung vor_Skript. Lassen Sie mich diesen Teil etwas erklären.

Vorbereitung zur 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- und Analyse-Repositorys:

  - 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.

Projektabhängigkeiten wiederherstellen, wo $CI_PROJECT_DIR – vollständiger Pfad zum Projektverzeichnis:

  - 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 heruntergeladen werden).

Sie können Umgebungsvariablen mit Lizenzinformationen festlegen, indem Sie auf klicken Rahmen, und danach - weiter CI/CD.

Suchen Sie im sich öffnenden Fenster nach dem Element Variablen, klicken Sie mit der rechten Maustaste auf die Schaltfläche Erweitern Sie die Funktionalität der und Variablen hinzufügen. Das Ergebnis sollte wie folgt aussehen:

Jetzt können wir mit der Analyse fortfahren. Fügen wir zunächst ein Skript für eine vollständige Analyse hinzu. Zur Fahne -t Geben Sie den Pfad zur Lösung an die Flagge weiter -o Schreiben Sie den Pfad zu der Datei, in die die Analyseergebnisse geschrieben werden. Uns interessiert auch der Returncode. In diesem Fall sind wir daran interessiert, die Arbeit zu stoppen, wenn der Rückkehrcode Informationen darüber enthält, dass während der Analyse Warnungen ausgegeben wurden. So sieht der Ausschnitt 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 nach dem Prinzip einer Bitmaske. Wenn als Ergebnis der Analyse beispielsweise Warnungen ausgegeben wurden, lautet der Rückkehrcode 8. Wenn die Lizenz innerhalb eines Monats abläuft, lautet der Rückkehrcode 4. Wenn bei der Analyse Fehler festgestellt wurden, gilt auch die Lizenz innerhalb eines Monats abläuft, werden in der Code-Rückgabe beide Werte geschrieben: Addieren Sie die Zahlen und erhalten Sie den endgültigen Rückgabecode – 8 + 4 = 12. Durch die Prüfung der entsprechenden Bits ist es somit möglich, während der Analyse Informationen über verschiedene Zustände zu erhalten. Rückgabecodes werden im Abschnitt pvs-studio-dotnet (Linux/MacOS) Rückgabecodes des Dokuments ausführlicher beschrieben.Überprüfen von Visual Studio-/MSBuild-/.NET Core-Projekten über die Befehlszeile mit PVS-Studio".

In diesem Fall interessieren uns alle Returncodes, bei denen 8 vorkommt.

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

Wir erhalten 1, wenn der Rückkehrcode das Bit der Zahl 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 müssen es nur ausführen, wenn eine Zusammenführungsanforderung auftritt. Es sieht aus wie das:

merge:
  script:
  only:
  - merge_requests

Kommen wir zum Skript selbst. Ich bin auf die Tatsache gestoßen, dass die virtuelle Maschine nichts davon weiß Herkunft/Meister. Helfen wir ihr also ein wenig:

  - git fetch origin

Jetzt ermitteln wir die Differenz der Zweige und speichern das Ergebnis in txt Datei:

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

Wo $CI_COMMIT_SHA – Hash des letzten Commits.

Als nächstes beginnen wir mit der Analyse der Dateiliste mithilfe der Flagge -f. Darauf übertragen wir die zuvor erhaltene .txt-Datei. Nun, analog zur vollständigen Analyse schauen wir uns die Rückgabecodes an:

  - 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 zur Prüfung 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

Nachdem alle Skripte funktioniert haben, muss nur noch die Protokollkonvertierung hinzugefügt werden. Verwendung des Etiketts after_script und Nutzen Plog-Konverter:

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

Dienstprogramm Plog-Konverter ist ein Open-Source-Projekt, das zur Konvertierung des Parser-Fehlerberichts in verschiedene Formen wie HTML verwendet wird. Eine ausführlichere Beschreibung des Dienstprogramms finden Sie im Unterabschnitt „Plog Converter Utility“. entsprechenden Abschnitt der Dokumentation.

Übrigens, wenn Sie bequem lokal aus der IDE heraus mit einem .json-Bericht arbeiten möchten, dann empfehle ich Ihnen unseren Plugin für IDE Rider. Seine Verwendung wird ausführlicher beschrieben in wichtiges Dokument.

Der Einfachheit halber hier .gitlab-ci.yml ganz:

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 -> Laufen. Es öffnet sich das Fenster der virtuellen Maschine, an dessen Ende Folgendes stehen sollte:

gesehen Job war erfolgreich - Erfolg, alles ist gut. Jetzt können Sie testen, was Sie getan haben.

Arbeitsbeispiele

Als Arbeitsbeispiel erstellen wir ein einfaches Projekt (in Master), die mehrere Dateien enthält. Danach werden wir in einem anderen Zweig nur eine Datei ändern und versuchen, eine Zusammenführungsanforderung zu stellen.

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

Nehmen wir an, es gibt eine Datei im Hauptzweig Programm.cs, das keine Fehler enthält, und in einem anderen Zweig hat der Entwickler fehlerhaften Code hinzugefügt und möchte eine Zusammenführungsanforderung stellen. Was für einen Fehler er gemacht hat, ist nicht so wichtig, Hauptsache, er existiert. Ich habe zum Beispiel den Operator vergessen werfen (Ja, 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 das Flag hinzugefügt -r zur pvs-studio-dotnet-Startzeile:

Wir sehen, dass der Analysator einen Fehler gefunden hat und die Zusammenführung der Zweige nicht zugelassen hat.

Schauen wir uns das Beispiel ohne Fehler an. Den Code reparieren:

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

Ergebnisse der Zusammenführungsanforderungsanalyse:

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

Abschluss

Das Aussortieren von fehlerhaftem Code vor dem Zusammenführen von Zweigen ist sehr praktisch und angenehm. Wenn Sie CI/CD verwenden, versuchen Sie daher, einen statischen Analysator einzubetten, um dies zu überprüfen. 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 Merge-Anfragen in GitLab mit PVS-Studio für C#.

Source: habr.com