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

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

Analyse der Commits und Pull Requests in Travis CI, Buddy und AppVeyor mithilfe von PVS-Studio
Im PVS-Studio-Analyser für die Programmiersprachen C und C++ unter Linux und macOS gibt es seit Version 7.04 eine Testfunktion, um die Liste der angegebenen Dateien zu überprüfen. Mit dem neuen Modus kann der Analyser so konfiguriert werden, dass er Commits und Pull Requests überprüft. In diesem Artikel wird erläutert, wie die Überprüfung der Liste der geänderten Dateien eines GitHub-Projekts in gängigen CI-Systemen wie Travis CI, Buddy und AppVeyor eingerichtet werden kann.

Modus zur Überprüfung von Dateilisten

PVS-Studio ist ein Werkzeug zur Erkennung von Fehlern und potenziellen Schwachstellen im Quellcode von Programmen, die in den Sprachen C, C++, C# und Java geschrieben sind. Es arbeitet auf 64-Bit-Systemen unter Windows, Linux und macOS.

In der Version PVS-Studio 7.04 für Linux und macOS gibt es einen Modus zur Überprüfung der Liste der Quellcodedateien. Dies funktioniert für Projekte, deren Build-System die Erstellung einer Datei ermöglicht. compile_commands.json. Diese Datei wird benötigt, damit der Analyser Informationen über die Kompilierung der angegebenen Dateien extrahieren kann. Wenn Ihr Build-System die Generierung einer Datei compile_commands.json nicht unterstützt, können Sie versuchen, eine solche Datei mit dem Hilfsprogramm zu erstellen. Bear.

Der Überprüfungsmodus für die Dateiliste kann auch in Verbindung mit dem Trace-Log strace der Compileraufrufe (pvs-studio-analyzer trace) verwendet werden. Dazu müssen Sie zunächst einen vollständigen Build des Projekts durchführen und diesen nachverfolgen, damit der Analyser vollständige Informationen zu den Kompilierungsparametern aller überprüften Dateien sammeln kann.

Allerdings hat diese Methode einen wesentlichen Nachteil – es muss entweder bei jedem Start eine vollständige Trace-Aufzeichnung des gesamten Projekts erstellt werden, was der Idee einer schnellen Überprüfung des Commits widerspricht. Oder wenn das Ergebnis der Trace-Aufzeichnung zwischengespeichert wird, könnten nachfolgende Starts des Analyzers unvollständig sein, wenn sich nach der Trace-Aufzeichnung die Struktur der Abhängigkeiten der Quellcodedateien ändert (zum Beispiel, wenn in eine der Quellcodedateien ein neuer #include hinzugefügt wird).

Deshalb empfehlen wir, den Modus zur Überprüfung der Dateiliste mit Trace-Logs nicht zur Überprüfung von Commits oder Pull Requests zu verwenden. Falls Sie bei der Überprüfung von Commits inkrementelle Builds durchführen können, ziehen Sie in Betracht, den Modus inkrementelle Analyse.

Die Liste der Quellcodedateien, die analysiert werden sollen, wird in einer Textdatei gespeichert und dem Analyzer über den Parameter -S:

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

In dieser Datei werden relative oder absolute Pfade zu Dateien angegeben, wobei jede neue Datei in einer neuen Zeile stehen muss. Es ist zulässig, nicht nur Dateinamen zur Analyse anzugeben, sondern auch verschiedene Texte. Der Analyzer wird erkennen, dass es sich nicht um eine Datei handelt und die Zeile ignorieren. Dies kann nützlich sein, um Kommentare zu hinterlassen, wenn Dateien manuell angegeben werden. Oft wird die Liste der Dateien jedoch während der Analyse im CI generiert, beispielsweise können dies Dateien aus einem Commit oder einem Pull Request sein.

Jetzt kann mit diesem Modus der neue Code schnell überprüft werden, bevor er in den Hauptentwicklungszweig gelangt. Damit das Prüfungssystem auf Warnungen des Analyzers reagiert, wird das Tool plog-converter wurde ein Flag hinzugefügt —indicate-warnings:

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

Mit diesem Flag gibt der Konverter einen von Null verschiedenen Code zurück, wenn im Bericht des Analyzers Warnungen vorhanden sind. Anhand des Rückgabecodes kann ein Pre-Commit-Hook, ein Commit oder ein Pull Request blockiert und der generierte Bericht des Analyzers auf dem Bildschirm ausgegeben, geteilt oder per E-Mail gesendet werden.

Hinweis. Bei der ersten Ausführung der Analyse der Liste von Dateien wird das gesamte Projekt analysiert, da der Analyzer eine Abhängigkeitsdatei der Quellkodierungsdateien des Projekts zu den Header-Dateien generieren muss. Dies ist ein Merkmal der Analyse von C- und C++-Dateien. In Zukunft kann die Abhängigkeitsdatei zwischengespeichert werden, und sie wird automatisch vom Analyzer aktualisiert. Der Vorteil der Überprüfung von Commits bei Verwendung des Modus zur Überprüfung der Dateiliste im Vergleich zur Verwendung des Modus der inkrementellen Analyse besteht darin, dass nur diese Datei zwischengespeichert werden muss, nicht die Objektdateien.

Allgemeine Prinzipien der Analyse eines Pull Requests

Die Analyse des gesamten Projekts benötigt viel Zeit, daher macht es Sinn, nur einen Teil davon zu überprüfen. Das Problem besteht darin, dass neue Dateien von den anderen Dateien des Projekts getrennt werden müssen.

Betrachten wir ein Beispiel eines Commit-Baums mit zwei Branches:

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

Stellen wir uns vor, dass der Commit A1 eine ausreichend große Menge an Code enthält, die bereits überprüft wurde. Vorher haben wir einen Branch von dem Commit A1 abgezweigt und einige Dateien geändert.

Sie haben sicherlich bemerkt, dass nach A1 noch zwei Commits stattfanden, aber dies waren auch Zusammenführungen anderer Branches, schließlich committen wir ja nicht in master. Und jetzt ist der Zeitpunkt gekommen, an dem Hotfix bereit ist. Daher wurde ein Pull Request für die Zusammenführung erstellt. B3 und A3.

Natürlich könnte man das gesamte Ergebnis ihrer Zusammenführung überprüfen, aber das wäre zu langwierig und unjustifiziert, da nur einige Dateien geändert wurden. Daher ist es effizienter, nur die Änderungen zu analysieren.

Dafür erhalten wir den Unterschied zwischen den Branches, während wir uns im HEAD des Branches befinden, den wir in master zusammenführen möchten:

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

$MERGE_BASE wir werden das später im Detail besprechen. Es ist so, dass nicht jeder CI-Dienst die erforderlichen Informationen zur Basis für die Zusammenführung bereitstellt, weshalb es jedes Mal notwendig ist, neue Wege zu finden, diese Daten zu erhalten. Das wird unten in jedem beschriebenen Webdienst ausführlich erklärt.

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

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 verständliches Format konvertieren:

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

Dieser Befehl gibt eine Fehlerliste in stderr (Standard-Ausgabestrom für Fehlermeldungen) aus.

Wir müssen jedoch nicht nur die Fehler ausgeben, sondern auch unserem Build- und Testdienst von den vorhandenen Problemen berichten. Zu diesem Zweck wurde dem Konverter das Flag -W (—indicate-warnings) hinzugefügt. Wenn der Analysator auch nur eine Warnung ausgibt, wird der Rückgabewert des Dienstprogramms plog-converter auf 2 ändern, was wiederum dem CI-Dienst signalisiert, dass potenzielle Fehler in den Dateien des Pull-Requests vorliegen.

Travis CI

Die Konfiguration erfolgt in Form einer Datei .travis.yml. Zur Vereinfachung empfehle ich, alles in ein separates Bash-Skript mit Funktionen auszulagern, die aus der Datei aufgerufen werden. .travis.yml (bash name_des_skripts.sh name_der_funktion).

Wir werden den notwendigen Code in das Skript auf bashhinzufügen, dadurch erhalten wir erweiterte Funktionalität. Im Abschnitt install werden wir Folgendes schreiben:

install:
  - bash .travis.sh travis_install

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

Wir öffnen die Datei .travis.sh und fügen die Installation des Analysators in die Funktion ein 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 
}

Jetzt fügen wir im Abschnitt script den Start der Analyse hinzu:

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 sollte nach dem Build des Projekts ausgeführt werden, beispielsweise wenn Sie ein CMake-Build hatten:

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

Es wird so aussehen:

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
}

Sie haben wahrscheinlich bereits die angegebenen Umgebungsvariablen bemerkt: $TRAVIS_PULL_REQUEST und $TRAVIS_BRANCH. Travis CI erklärt sie selbst:

  • $TRAVIS_PULL_REQUEST speichert die Nummer des Pull Requests oder false, wenn es sich um einen normalen Branch handelt;
  • $TRAVIS_REPO_SLUG speichert den Namen des Projekt-Repositorys.

Der Ablauf dieser Funktion:

Analyse der Commits und Pull Requests in Travis CI, Buddy und AppVeyor mithilfe von PVS-Studio
Travis CI reagiert auf Rückgabecodes, daher wird das Vorhandensein von Warnungen den Dienst dazu veranlassen, den Commit als fehlerhaft zu kennzeichnen.

Schauen wir uns nun diese Codezeile genauer an:

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

Das Problem ist, dass Travis CI während der Analyse des Pull Requests automatisch Branches zusammenführt:

Analyse der Commits und Pull Requests in Travis CI, Buddy und AppVeyor mithilfe von PVS-Studio
Deshalb analysieren wir A4, nicht B3->A3. Aufgrund dieser Besonderheit müssen wir den Unterschied zu A3berechnen, das genau das Ende des Branches aus origin.

bleibt noch ein wichtiger Punkt – das Caching von Abhängigkeiten von Header-Dateien der zu kompilierenden Übersetzungseinheiten (*.c, *.cc, *.cpp usw.). Diese Abhängigkeiten berechnet der Analyzer beim ersten Durchlauf im Dateiliste-Prüfmodus und speichert sie dann im Verzeichnis .PVS-Studio. Travis CI erlaubt das Caching von Ordnern, daher werden wir die Daten des Verzeichnisses .PVS-Studio/:

cache:
  directories:
    - .PVS-Studio/

Dieser Code muss in die Datei eingefügt werden .travis.yml. Dieses Verzeichnis speichert verschiedene Daten, die nach der Analyse gesammelt wurden, und beschleunigt damit die nachfolgenden Ausführungen der Dateianalyse oder der inkrementellen Analyse erheblich. Andernfalls würde der Analysator jedes Mal alle Dateien analysieren.

Buddy

Wie Travis CI Buddy bietet die Möglichkeit zur automatisierten Erstellung und Testung von Projekten, die auf GitHub gespeichert sind. Im Gegensatz zu Travis CI wird es über eine Web-Oberfläche konfiguriert (Bash-Unterstützung ist vorhanden), daher ist es nicht notwendig, Konfigurationsdateien im Projekt zu speichern.

Zuerst müssen wir eine neue Aktion in der Build-Pipeline hinzufügen:

Analyse der Commits und Pull Requests in Travis CI, Buddy und AppVeyor mithilfe von PVS-Studio
Wir geben den Compiler an, der für den Build des Projekts verwendet wurde. Beachten Sie den Docker-Container, der in dieser Aktion eingerichtet ist. Zum Beispiel gibt es für GCC einen speziellen Container:

Analyse der Commits und Pull Requests in Travis CI, Buddy und AppVeyor mithilfe von PVS-Studio
Jetzt installieren wir PVS-Studio und die erforderlichen Dienstprogramme:

Analyse der Commits und Pull Requests in Travis CI, Buddy und AppVeyor mithilfe von PVS-Studio
Fügen Sie im 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

Jetzt wechseln wir zum Tab "Run" (das erste Symbol) und fügen im entsprechenden Feld des Editors folgenden Code hinzu:

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 Travis-CI gelesen haben, wird Ihnen dieser Code bereits bekannt sein, jedoch gibt es jetzt eine neue Stufe:

Analyse der Commits und Pull Requests in Travis CI, Buddy und AppVeyor mithilfe von PVS-Studio
Der Punkt ist, dass wir jetzt nicht das Ergebnis der Zusammenführung analysieren, sondern den HEAD des Zweigs, aus dem der Pull-Request gemacht wird:

Analyse der Commits und Pull Requests in Travis CI, Buddy und AppVeyor mithilfe von PVS-Studio
Deshalb befinden wir uns in einem bedingten Commit B3 und wir müssen die Differenz zu 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

Zur Erkennung A3 wir verwenden 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 — die Nummer des Pull-Requests;
  • $BUDDY_REPO_SLUG — die Kombination aus Benutzernamen und Repository (zum Beispiel max/test).

Lass uns jetzt die Änderungen speichern, indem wir die Schaltfläche unten verwenden, und die Analyse des Pull Requests aktivieren:

Analyse der Commits und Pull Requests in Travis CI, Buddy und AppVeyor mithilfe von PVS-Studio
Im Gegensatz zu Travis CI müssen wir nicht angeben .pvs-studio für das Caching, da Buddy automatisch alle Dateien für nachfolgende Ausführungen zwischenspeichert. Daher bleibt nur noch eines — die Anmeldeinformationen für PVS-Studio in Buddy zu speichern. Nach dem Speichern der Änderungen gelangen wir zurück zu Pipeline. Wir müssen die Variablenkonfiguration aufrufen und Anmeldeinformationen und Schlüssel für PVS-Studio hinzufügen:

Analyse der Commits und Pull Requests in Travis CI, Buddy und AppVeyor mithilfe von PVS-Studio
Nach diesem Schritt wird das Erscheinen eines neuen Pull Requests oder Commits eine Überprüfung auslösen. Wenn der Commit Fehler enthält, wird Buddy darauf auf der Seite des Pull Requests hinweisen.

AppVeyor

Die Konfiguration von AppVeyor ähnelt der von Buddy, da alles im Webinterface erfolgt und es nicht erforderlich ist, eine Datei *.yml ins Projekt-Repository hinzuzufügen.

Gehen wir auf den Reiter Einstellungen im Projektüberblick:

Analyse der Commits und Pull Requests in Travis CI, Buddy und AppVeyor mithilfe von PVS-Studio
Scrollen wir nach unten und aktivieren wir das Caching für die Builds der Pull Requests:

Analyse der Commits und Pull Requests in Travis CI, Buddy und AppVeyor mithilfe von PVS-Studio
Jetzt gehen wir auf den Reiter Umgebung, wo wir das Abbild für den Build und die benötigten Umgebungsvariablen angeben:

Analyse der Commits und Pull Requests in Travis CI, Buddy und AppVeyor mithilfe von PVS-Studio
Wenn du die vorherigen Abschnitte gelesen hast, bist du mit diesen beiden Variablen gut vertraut — PVS_KEY und PVS_USERNAME. Falls nicht, erinnere ich daran, dass sie notwendig sind, um die Lizenz des PVS-Studio Analysators zu überprüfen. In Zukunft werden wir ihnen in Bash-Skripten erneut begegnen.

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

Analyse der Commits und Pull Requests in Travis CI, Buddy und AppVeyor mithilfe von PVS-Studio
Wenn wir das nicht tun, werden wir anstelle von ein paar Dateien das gesamte Projekt analysieren, aber die Ausgabe wird nur für die angegebenen Dateien erfolgen. Daher ist es wichtig, den korrekten Namen des Verzeichnisses einzugeben.

Jetzt ist es Zeit für das Skript zur Überprüfung. Öffnen wir den Reiter Tests und wählen Script aus:

Analyse der Commits und Pull Requests in Travis CI, Buddy und AppVeyor mithilfe von PVS-Studio
In dieses Feld muss der folgende Code eingefügt werden:

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

Lassen Sie uns auf den folgenden Teil des Codes achten:

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 spezifische Zuweisung des Wertes des Befehls pwd an eine Variable, die diesen Wert standardmäßig speichern soll, mag auf den ersten Blick seltsam erscheinen, aber ich werde alles jetzt erklären.

Während der Konfiguration des Analysators in AppVeyor stieß ich auf ein äußerst merkwürdiges Verhalten des Analysators. Einerseits funktionierte alles korrekt, aber die Analyse wurde nicht gestartet. Ich verbrachte eine Weile damit, zu bemerken, dass wir uns im Verzeichnis /home/appveyor/projects/testcalc/ befinden, während der Analysator überzeugt war, wir seien in /opt/appveyor/build-agent/. Da wurde mir klar, dass die Variable $PWD ein wenig lügt. Aus diesem Grund habe ich ihren Wert manuell vor dem Start der Analyse aktualisiert.

Und weiter geht's wie zuvor:

Analyse der Commits und Pull Requests in Travis CI, Buddy und AppVeyor mithilfe von PVS-Studio
Nun betrachten wir den nächsten Abschnitt:

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"`

Hier erhalten wir die Unterschiede zwischen den Branches, für die ein Pull-Request erklärt wurde. Dazu benötigen wir die folgenden Umgebungsvariablen:

  • $APPVEYOR_PULL_REQUEST_NUMBER — die Nummer des Pull-Requests;
  • $APPVEYOR_REPO_NAME — den Benutzernamen und das Repository des Projekts.

Fazit

Natürlich haben wir nicht alle möglichen Continuous Integration-Services betrachtet, aber sie haben alle eine äußerst ähnliche Arbeitsweise. Abgesehen vom Caching erstellt jeder Service sein eigenes "Fahrrad", weshalb die Dinge immer unterschiedlich sind.

Irgendwo, wie bei Travis-CI, sind ein paar Zeilen Code ausreichend und das Caching funktioniert einwandfrei; irgendwo, wie bei AppVeyor, muss einfach der Ordner in den Einstellungen angegeben werden; aber irgendwo müssen einzigartige Schlüssel erstellt und versucht werden, das System davon zu überzeugen, dir das Überschreiben des zwischengespeicherten Teils zu ermöglichen. Daher solltest du, wenn du die Analyse von Pull-Requests auf einem Continuous Integration-Service einrichten möchtest, der oben nicht behandelt wurde, zunächst sicherstellen, dass du beim Caching keine Probleme haben wirst.

Vielen Dank für deine Aufmerksamkeit. Wenn etwas nicht funktioniert, schreib uns gerne an Unterstützung. Wir werden helfen und unterstützen.

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

Wenn Sie diesen Artikel mit einem englischsprachigen Publikum teilen möchten, verwenden Sie bitte den Link zur Übersetzung: Maxim Zvyagintsev. Analyse von Commits und Pull Requests in Travis CI, Buddy und AppVeyor mit PVS-Studio.

Quelle: habr.com

60GB SSD 8Gb DDR4