🥇Analyse von Commits und Pull Requests in Travis CI, Buddy und AppVeyor mit PVS-Studio

Im PVS-Studio-Analysator für C- und C++-Sprachen unter Linux und macOS ist ab Version 7.04 eine Testoption zum Überprüfen der Liste der angegebenen Dateien erschienen. Mit dem neuen Modus können Sie den Analysator so konfigurieren, dass er Commits und Pull-Requests überprüft. In diesem Artikel erfahren Sie, wie Sie die Überprüfung der Liste der geänderten Dateien eines GitHub-Projekts in so beliebten CI-Systemen (Continuous Integration) wie Travis CI, Buddy und AppVeyor einrichten.

Dateilisten-Überprüfungsmodus

PVS Studio ist ein Tool zur Identifizierung 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.

In der Version PVS-Studio 7.04 für Linux und macOS ist ein Modus zum Überprüfen der Liste der Quelldateien erschienen. Dies funktioniert für Projekte, deren Build-System es Ihnen ermöglicht, eine Datei zu generieren compile_commands.json. Es wird für den Analysator benötigt, um Informationen über die Zusammenstellung der angegebenen Dateien zu extrahieren. Wenn Ihr Build-System das Generieren der Datei „compile_commands.json“ nicht unterstützt, können Sie versuchen, eine solche Datei mit dem Dienstprogramm zu generieren Denken Sie.

Außerdem kann der Dateilisten-Überprüfungsmodus zusammen mit dem Strace-Trace-Protokoll von Compiler-Starts (Pvs-Studio-Analyzer-Trace) verwendet werden. Dazu müssen Sie zunächst eine vollständige Erstellung des Projekts durchführen und diese verfolgen, damit der Analysator vollständige Informationen über die Kompilierungsparameter aller überprüften Dateien sammelt.

Diese Option hat jedoch einen erheblichen Nachteil: Sie müssen entweder bei jeder Ausführung einen vollständigen Build-Trace des gesamten Projekts durchführen, was an sich der Idee einer schnellen Überprüfung eines Commits widerspricht. Wenn Sie das Trace-Ergebnis selbst zwischenspeichern, können nachfolgende Ausführungen des Analysetools möglicherweise unvollständig sein, wenn sich die Abhängigkeitsstruktur der Quelldateien nach dem Trace ändert (z. B. wenn einer der Quelldateien ein neues #include hinzugefügt wird).

Daher empfehlen wir nicht, den Dateilisten-Prüfmodus mit dem Trace-Protokoll zu verwenden, um Commits oder Pull-Anfragen zu überprüfen. Falls Sie beim Überprüfen eines Commits einen inkrementellen Build durchführen können, sollten Sie die Verwendung des Modus in Betracht ziehen inkrementelle Analyse.

Die Liste der zu analysierenden Quelldateien wird in einer Textdatei gespeichert und mithilfe des Parameters an den Analysator übergeben -S:

pvs-studio-analyzer analyze ... -f build/compile_commands.json -S check-list.txt

Diese Datei gibt relative oder absolute Pfade zu Dateien an und jede neue Datei muss in einer neuen Zeile stehen. Es ist akzeptabel, nicht nur Dateinamen für die Analyse anzugeben, sondern auch verschiedene Texte. Der Analysator erkennt, dass es sich nicht um eine Datei handelt und ignoriert die Zeile. Dies kann zum Kommentieren nützlich sein, wenn Dateien manuell angegeben werden. Bei der Analyse in CI wird jedoch häufig eine Liste von Dateien generiert. Dabei kann es sich beispielsweise um Dateien aus einem Commit- oder Pull-Request handeln.

Mit diesem Modus können Sie jetzt neuen Code schnell überprüfen, bevor er in den Hauptentwicklungszweig gelangt. Um sicherzustellen, dass das Scansystem auf Warnungen des Analysegeräts reagiert, muss das Dienstprogramm Plog-Konverter Flagge hinzugefügt --indicate-warnings:

plog-converter ... --indicate-warnings ... -o /path/to/report.tasks ...

Mit diesem Flag gibt der Konverter einen Code ungleich Null zurück, wenn im Analysebericht Warnungen vorhanden sind. Mithilfe des Rückgabecodes können Sie einen Precommit-Hook, einen Commit oder eine Pull-Anfrage blockieren und der generierte Analysebericht kann angezeigt, geteilt oder per E-Mail gesendet werden.

Notiz. Wenn Sie zum ersten Mal mit der Analyse einer Dateiliste beginnen, wird das gesamte Projekt analysiert, weil Der Analysator muss eine Datei mit Abhängigkeiten der Projektquelldateien von den Headerdateien generieren. Dies ist eine Funktion zur Analyse von C- und C++-Dateien. Zukünftig kann die Abhängigkeitsdatei zwischengespeichert werden und wird vom Analysator automatisch aktualisiert. Der Vorteil der Überprüfung von Commits im Dateilisten-Prüfmodus gegenüber der Verwendung des inkrementellen Analysemodus besteht darin, dass Sie nur diese Datei und nicht die Objektdateien zwischenspeichern müssen.

Allgemeine Prinzipien der Pull-Request-Analyse

Die Analyse des gesamten Projekts nimmt viel Zeit in Anspruch, daher ist es sinnvoll, nur einen bestimmten Teil davon zu überprüfen. Das Problem besteht darin, dass Sie die neuen Dateien von den übrigen Projektdateien trennen müssen.

Schauen wir uns ein Beispiel eines Commit-Baums mit zwei Zweigen an:

Stellen wir uns diesen Commit vor A1 enthält eine ziemlich große Menge Code, der bereits getestet wurde. Etwas früher haben wir einen Zweig vom Commit erstellt A1 und einige Dateien geändert.

Das haben Sie natürlich später gemerkt A1 Es kam zu zwei weiteren Commits, aber auch dabei handelte es sich um Fusionen anderer Branches, zu denen wir uns nicht verpflichten Master. Und jetzt ist die Zeit gekommen Hotfix bereit. Aus diesem Grund erschien ein Pull-Request für den Zusammenschluss B3 и A3.

Natürlich wäre es möglich, das gesamte Ergebnis ihrer Fusion zu überprüfen, aber das wäre zu aufwendig und ungerechtfertigt, da nur wenige Dateien geändert wurden. Daher ist es effizienter, nur die geänderten zu analysieren.

Dazu ermitteln wir den Unterschied zwischen den Zweigen, indem wir uns im HEAD des Zweigs befinden, von dem aus wir zum Master zusammenführen möchten:

git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list

$MERGE_BASE Wir werden es uns später im Detail ansehen. Tatsache ist, dass nicht jeder CI-Dienst die für die Zusammenführung erforderlichen Informationen über die Datenbank bereitstellt, sodass Sie jedes Mal neue Wege finden müssen, um diese Daten zu erhalten. Dies wird im Folgenden bei jedem der beschriebenen Webdienste ausführlich beschrieben.

Wir haben also den Unterschied zwischen den Zweigen erhalten, oder besser gesagt, eine Liste der Dateinamen, die geändert wurden. Jetzt müssen wir die Datei übergeben .pvs-pr.list (wir haben die obige Ausgabe darauf umgeleitet) an den Analysator:

pvs-studio-analyzer analyze -j8 
                            -o PVS-Studio.log 
                            -S .pvs-pr.list

Nach der Analyse müssen wir die Protokolldatei (PVS-Studio.log) in ein leicht lesbares Format konvertieren:

plog-converter -t errorfile PVS-Studio.log --cerr -w

Dieser Befehl listet die Fehler auf stderr (Standard-Fehlermeldungsausgabe).

Erst jetzt müssen wir nicht nur Fehler anzeigen, sondern auch unseren Service für Montage und Prüfung über das Vorliegen von Problemen informieren. Zu diesem Zweck wurde dem Konverter ein Flag hinzugefügt -W (--indicate-warnings). Wenn mindestens eine Analysewarnung vorliegt, der Rückgabecode des Dienstprogramms Plog-Konverter wird zu 2 geändert, was wiederum den CI-Dienst über das Vorhandensein potenzieller Fehler in den Pull-Request-Dateien informiert.

Travis CI

Die Konfiguration erfolgt als Datei .travis.yml. Der Einfachheit halber empfehle ich Ihnen, alles in ein separates Bash-Skript mit Funktionen zu packen, die aus der Datei aufgerufen werden .travis.yml (Bash-Skriptname.sh Funktionsname).

Wir werden dem Skript unter den erforderlichen Code hinzufügen bash, auf diese Weise erhalten wir mehr Funktionalität. Im Abschnitt installieren lasst uns Folgendes schreiben:

install:
  - bash .travis.sh travis_install

Wenn Sie Anweisungen hatten, können Sie diese in das Skript übertragen und dabei die Bindestriche entfernen.

Lassen Sie uns die Datei öffnen .travis.sh und fügen Sie die Analysatoreinstellung zur Funktion hinzu travis_install():

travis_install() {
  wget -q -O - https://files.viva64.com/etc/pubkey.txt 
    | sudo apt-key add -
  sudo wget -O /etc/apt/sources.list.d/viva64.list 
    https://files.viva64.com/etc/viva64.list
  
  sudo apt-get update -qq
  sudo apt-get install -qq pvs-studio 
}

Nun ergänzen wir den Abschnitt Skript Laufanalyse:

script:
  - bash .travis.sh travis_script

Und im Bash-Skript:

travis_script() {
  pvs-studio-analyzer credentials $PVS_USERNAME $PVS_KEY
  
  if [ "$TRAVIS_PULL_REQUEST" != "false" ]; then
    git diff --name-only origin/HEAD > .pvs-pr.list
    pvs-studio-analyzer analyze -j8 
                                -o PVS-Studio.log 
                                -S .pvs-pr.list 
                                --disableLicenseExpirationCheck
  else
    pvs-studio-analyzer analyze -j8 
                                -o PVS-Studio.log 
                                --disableLicenseExpirationCheck
  fi
  
  plog-converter -t errorfile PVS-Studio.log --cerr -w
}

Dieser Code muss nach dem Erstellen des Projekts ausgeführt werden, wenn Sie beispielsweise einen Build auf CMake hatten:

travis_script() {
  CMAKE_ARGS="-DCMAKE_EXPORT_COMPILE_COMMANDS=On ${CMAKE_ARGS}"
  cmake $CMAKE_ARGS CMakeLists.txt
  make -j8
}

Es wird so ausgehen:

travis_script() {
  CMAKE_ARGS="-DCMAKE_EXPORT_COMPILE_COMMANDS=On ${CMAKE_ARGS}"
  cmake $CMAKE_ARGS CMakeLists.txt
  make -j8
  
  pvs-studio-analyzer credentials $PVS_USERNAME $PVS_KEY
  
  if [ "$TRAVIS_PULL_REQUEST" != "false" ]; then
    git diff --name-only origin/HEAD > .pvs-pr.list
    pvs-studio-analyzer analyze -j8 
                                -o PVS-Studio.log 
                                -S .pvs-pr.list 
                                --disableLicenseExpirationCheck
  else
    pvs-studio-analyzer analyze -j8 
                                -o PVS-Studio.log 
                                --disableLicenseExpirationCheck
  fi
  
  plog-converter -t errorfile PVS-Studio.log --cerr -w
}

Diese Umgebungsvariablen sind Ihnen wahrscheinlich bereits aufgefallen $TRAVIS_PULL_REQUEST и $TRAVIS_BRANCH. Travis CI erklärt sie unabhängig:

$TRAVIS_PULL_REQUEST speichert die Pull-Request-Nummer oder falsch, wenn es sich um einen regulären Zweig handelt;
$TRAVIS_REPO_SLUG speichert den Namen des Projekt-Repositorys.

Der Algorithmus für diese Funktion:

Travis CI antwortet auf Rückkehrcodes, sodass der Dienst bei Vorhandensein von Warnungen angewiesen wird, den Commit als fehlerhaft zu markieren.

Schauen wir uns nun diese Codezeile genauer an:

git diff --name-only origin/HEAD > .pvs-pr.list

Tatsache ist, dass Travis CI bei der Analyse einer Pull-Anfrage automatisch Zweige zusammenführt:

Deshalb analysieren wir A4Und nicht B3->A3. Aufgrund dieser Funktion müssen wir die Differenz mit berechnen A3, das ist genau die Spitze des Zweigs von Herkunft.

Es bleibt noch ein wichtiges Detail übrig – das Zwischenspeichern der Abhängigkeiten von Header-Dateien von kompilierten Übersetzungseinheiten (*.c, *.cc, *.cpp usw.). Der Analysator berechnet diese Abhängigkeiten, wenn er zum ersten Mal im Modus zur Überprüfung einer Dateiliste gestartet wird, und speichert sie dann im Verzeichnis .PVS-Studio. Mit Travis CI können Sie Ordner zwischenspeichern, sodass wir die Verzeichnisdaten speichern .PVS-Studio/:

cache:
  directories:
    - .PVS-Studio/

Dieser Code muss der Datei hinzugefügt werden .travis.yml. In diesem Verzeichnis werden verschiedene nach der Analyse gesammelte Daten gespeichert, wodurch nachfolgende Dateilistenanalysen oder inkrementelle Analysen erheblich beschleunigt werden. Geschieht dies nicht, analysiert der Analysator tatsächlich jedes Mal alle Dateien.

Kumpel

Wie Travis CI, Kumpel bietet die Möglichkeit, auf GitHub gespeicherte Projekte automatisch zu erstellen und zu testen. Im Gegensatz zu Travis CI wird es im Webinterface konfiguriert (Bash-Unterstützung ist verfügbar), sodass keine Konfigurationsdateien im Projekt gespeichert werden müssen.

Zunächst müssen wir dem Fließband eine neue Aktion hinzufügen:

Geben wir den Compiler an, der zum Erstellen des Projekts verwendet wurde. Beachten Sie den Docker-Container, der in dieser Aktion installiert wird. Für GCC gibt es beispielsweise einen speziellen Container:

Jetzt installieren wir PVS-Studio und die notwendigen Dienstprogramme:

Fügen wir dem Editor die folgenden Zeilen hinzu:

apt-get update && apt-get -y install wget gnupg jq

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

Gehen wir nun zur Registerkarte „Ausführen“ (erstes Symbol) und fügen Sie den folgenden Code in das entsprechende Editorfeld ein:

pvs-studio-analyzer credentials $PVS_USERNAME $PVS_KEY

if [ "$BUDDY_EXECUTION_PULL_REQUEST_NO" != '' ]; then
  PULL_REQUEST_ID="pulls/$BUDDY_EXECUTION_PULL_REQUEST_NO"
  MERGE_BASE=`wget -qO - 
    https://api.github.com/repos/${BUDDY_REPO_SLUG}/${PULL_REQUEST_ID} 
    | jq -r ".base.ref"`

  git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck 
                              -S .pvs-pr.list
else
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck
fi

plog-converter -t errorfile PVS-Studio.log --cerr -w

Wenn Sie den Abschnitt über Travs-CI lesen, ist Ihnen dieser Code bereits bekannt, jetzt gibt es jedoch eine neue Stufe:

Tatsache ist, dass wir jetzt nicht das Ergebnis der Zusammenführung analysieren, sondern den HEAD des Zweigs, von dem aus die Pull-Anfrage gestellt wird:

Wir befinden uns also in einem bedingten Commit B3 und wir müssen den Unterschied ausmachen A3:

PULL_REQUEST_ID="pulls/$BUDDY_EXECUTION_PULL_REQUEST_NO"
  MERGE_BASE=`wget -qO - 
    https://api.github.com/repos/${BUDDY_REPO_SLUG}/${PULL_REQUEST_ID} 
    | jq -r ".base.ref"`
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list

Zu bestimmen A3 Verwenden wir die GitHub-API:

https://api.github.com/repos/${USERNAME}/${REPO}/pulls/${PULL_REQUEST_ID}

Wir haben die folgenden Variablen verwendet, die Buddy bereitstellt:

$BUDDY_EXECUTION_PULL_REQEUST_NO — Pull-Request-Nummer;
$BUDDY_REPO_SLUG – eine Kombination aus Benutzername und Repository (z. B. max/test).

Speichern wir nun die Änderungen über die Schaltfläche unten und aktivieren Sie die Analyse des Pull-Requests:

Im Gegensatz zu Travis CI müssen wir keine Angaben machen .pvs-studio zum Caching, da Buddy automatisch alle Dateien für spätere Starts zwischenspeichert. Daher bleibt als letztes noch das Speichern des Logins und Passworts für PVS-Studio in Buddy. Nachdem wir die Änderungen gespeichert haben, kehren wir zu Pipeline zurück. Wir müssen mit dem Einrichten von Variablen und dem Hinzufügen eines Logins und Schlüssels für PVS-Studio fortfahren:

Danach wird die Überprüfung durch das Erscheinen eines neuen Pull-Requests oder Commits ausgelöst. Wenn ein Commit Fehler enthält, zeigt Buddy dies auf der Pull-Request-Seite an.

AppVeyor

Das Einrichten von AppVeyor ähnelt dem von Buddy, da alles in der Weboberfläche geschieht und keine *.yml-Datei zum Projekt-Repository hinzugefügt werden muss.

Gehen wir in der Projektübersicht auf den Reiter „Einstellungen“:

Scrollen wir auf dieser Seite nach unten und aktivieren Sie die Cache-Speicherung zum Sammeln von Pull-Anfragen:

Gehen wir nun zur Registerkarte „Umgebung“, wo wir das Bild für die Montage und die erforderlichen Umgebungsvariablen angeben:

Wenn Sie die vorherigen Abschnitte gelesen haben, sind Sie mit diesen beiden Variablen sehr vertraut PVS_KEY и PVS_USERNAME. Wenn nicht, möchte ich Sie daran erinnern, dass sie zur Überprüfung der Lizenz des PVS-Studio-Analysegeräts erforderlich sind. Wir werden sie in Zukunft wieder in Bash-Skripten sehen.

Auf derselben Seite unten geben wir den Ordner für das Caching an:

Wenn wir dies nicht tun, analysieren wir das gesamte Projekt und nicht nur einige Dateien, erhalten aber die Ausgabe aus den angegebenen Dateien. Daher ist es wichtig, den richtigen Verzeichnisnamen einzugeben.

Jetzt ist es Zeit, das Skript zu testen. Öffnen Sie die Registerkarte Tests und wählen Sie Skript aus:

Sie müssen den folgenden Code in dieses Formular einfügen:

sudo apt-get update && sudo apt-get -y install jq

wget -q -O - https://files.viva64.com/etc/pubkey.txt 
  | sudo apt-key add -
sudo wget -O /etc/apt/sources.list.d/viva64.list 
  https://files.viva64.com/etc/viva64.list

sudo apt-get update && sudo apt-get -y install pvs-studio

pvs-studio-analyzer credentials $PVS_USERNAME $PVS_KEY

PWD=$(pwd -L)
if [ "$APPVEYOR_PULL_REQUEST_NUMBER" != '' ]; then
  PULL_REQUEST_ID="pulls/$APPVEYOR_PULL_REQUEST_NUMBER"
  MERGE_BASE=`wget -qO - 
    https://api.github.com/repos/${APPVEYOR_REPO_NAME}/${PULL_REQUEST_ID} 
    | jq -r ".base.ref"`

  git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck 
                              --dump-files --dump-log pvs-dump.log 
                              -S .pvs-pr.list
else
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck
fi

plog-converter -t errorfile PVS-Studio.log --cerr -w

Achten wir auf den folgenden Teil des Codes:

PWD=$(pwd -L)
if [ "$APPVEYOR_PULL_REQUEST_NUMBER" != '' ]; then
  PULL_REQUEST_ID="pulls/$APPVEYOR_PULL_REQUEST_NUMBER"
  MERGE_BASE=`wget -qO - 
   https://api.github.com/repos/${APPVEYOR_REPO_NAME}/${PULL_REQUEST_ID} 
   | jq -r ".base.ref"`

  git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck 
                              --dump-files --dump-log pvs-dump.log 
                              -S .pvs-pr.list
else
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck
fi

Die recht konkrete Zuweisung des Wertes des pwd-Befehls an eine Variable, die diesen Standardwert speichern soll, erscheint auf den ersten Blick seltsam, ich werde jetzt jedoch alles erklären.

Beim Einrichten des Analysators in AppVeyor bin ich auf ein äußerst seltsames Verhalten des Analysators gestoßen. Einerseits funktionierte alles korrekt, aber die Analyse startete nicht. Ich habe lange darauf geachtet, dass wir uns im Verzeichnis /home/appveyor/projects/testcalc/ befinden und der Analysator sicher ist, dass wir uns in /opt/appveyor/build-agent/ befinden. Dann wurde mir klar, dass die Variable $PWD ein wenig gelogen hat. Aus diesem Grund habe ich den Wert vor Beginn der Analyse manuell aktualisiert.

Und dann ist alles wie zuvor:

Betrachten Sie nun das folgende Fragment:

PULL_REQUEST_ID="pulls/$APPVEYOR_PULL_REQUEST_NUMBER"
MERGE_BASE=`wget -qO - 
  https://api.github.com/repos/${APPVEYOR_REPO_NAME}/${PULL_REQUEST_ID} 
  | jq -r ".base.ref"`

Darin erhalten wir den Unterschied zwischen den Zweigen, über die der Pull-Request deklariert wird. Dazu benötigen wir folgende Umgebungsvariablen:

$APPVEYOR_PULL_REQUEST_NUMBER – Nummer der Pull-Anfrage;
$APPVEYOR_REPO_NAME – Benutzername und Projekt-Repository.

Abschluss

Natürlich haben wir nicht alle möglichen Continuous-Integration-Dienste berücksichtigt, sie haben jedoch alle sehr ähnliche Betriebsspezifika. Mit Ausnahme des Cachings stellt jeder Dienst sein eigenes „Fahrrad“ her, sodass immer alles anders ist.

Irgendwo, wie in Travis-CI, funktionieren ein paar Codezeilen und das Caching einwandfrei; irgendwo, wie in AppVeyor, müssen Sie nur den Ordner in den Einstellungen angeben; Aber irgendwo müssen Sie eindeutige Schlüssel erstellen und versuchen, das System davon zu überzeugen, Ihnen die Möglichkeit zu geben, das zwischengespeicherte Fragment zu überschreiben. Wenn Sie also eine Pull-Request-Analyse für einen kontinuierlichen Integrationsdienst einrichten möchten, die oben nicht besprochen wurde, stellen Sie zunächst sicher, dass Sie keine Probleme mit dem Caching haben.

Vielen Dank für Ihre Aufmerksamkeit. Sollte etwas nicht klappen, schreiben Sie uns gerne an unterstützen. Wir beraten und helfen.

Wenn Sie diesen Artikel einem englischsprachigen Publikum zugänglich machen möchten, verwenden Sie bitte den Übersetzungslink: Maxim Zvyagintsev. Analyse von Commits und Pull Requests in Travis CI, Buddy und AppVeyor mit PVS-Studio.

Source: habr.com

Analyse von Commits und Pull Requests in Travis CI, Buddy und AppVeyor mit PVS-Studio