Analys av commits och pull requests i Travis CI, Buddy och AppVeyor med PVS-Studio

I analysatorn PVS-Studio för språken C och C++ på Linux och macOS, från version 7.04, har en testfunktion införts för att kontrollera listan över angivna filer. Med den nya läget kan analysatorn konfigureras för att kontrollera commits och pull requests. I denna artikel kommer vi att diskutera hur man ställer in kontrollen av listan med ändrade filer i ett GitHub-projekt i populära CI-system som Travis CI, Buddy och AppVeyor.

Filkontrollläge

PVS-Studio är ett verktyg för att identifiera fel och potentiella sårbarheter i programkod som skrivits i språk som C, C++, C# och Java. Det fungerar på 64-bitarsystem i Windows, Linux och macOS.

I version PVS-Studio 7.04 för Linux och macOS har ett filkontrollläge lagts till. Detta fungerar för projekt vars byggsystem kan generera en fil compile_commands.json. Denna fil behövs för att analysatorn ska kunna extrahera information om kompileringen av de angivna filerna. Om ditt byggsystem inte stöder generering av filen compile_commands.json kan du försöka generera en sådan fil med hjälp av verktyget Bear.

. Filkontrollläget kan också användas tillsammans med loggen från strace över kompilatorns körningar (pvs-studio-analyzer trace). För detta behöver du först genomföra en fullständig byggen av projektet och spåra den, så att analysatorn samlar in fullständig information om kompileringstillstånden för alla kontrollerade filer.

Men denna metod har en betydande nackdel - det krävs antingen att du gör en fullständig spårning av hela projektbyggen vid varje körning, vilket går emot syftet med snabb kontroll av commiten. Eller, om du cacher resultatet av spårningen, kan efterföljande körningar av analysatorn bli ofullständiga ifall struktureringen av beroendena i källfilerna ändras (till exempel om en ny #include läggs till i en av källfilerna).

Därför rekommenderar vi inte att använda filkontrollläget med spårningsloggen för att kontrollera commits eller pull requests. Om du kan göra en inkrementell byggning vid kontroll av en commit, överväg att använda läget inkrementell analys.

Listan över källfiler för analys sparas i en textfil och överlämnas till analysatorn med parametern -S:

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

Denna fil innehåller relativa eller absoluta sökvägar till filer, där varje ny fil ska anges på en ny rad. Det är tillåtet att ange inte bara filnamn för analysen, utan också olika text. Analysatorn kommer att se att detta inte är en fil och ignorera raden. Detta kan vara användbart för kommentar, om filerna anges manuellt. Men oftast kommer fillistan att genereras under analysen i CI, till exempel kan det vara filer från en commit eller pull request.

Nu kan man snabbt kontrollera ny kod innan den hamnar i huvudutvecklingsgrenen med hjälp av detta läge. För att kontrollsystemet ska reagera på analyserarens varningsmeddelanden, i verktyget plog-converter har en flagga lagts till —indicate-warnings:

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

Med detta flagga kommer konverteraren att returnera en icke-noll kod om det finns varningar i analyserarens rapport. Utifrån returkoden kan man blockera pre-commit hook, commit eller pull request, och den genererade analyserarens rapport kan visas på skärmen, delas eller skickas via e-post.

Observera. Vid första körningen av filanalysen kommer hela projektet att analyseras, eftersom analysatorn måste generera en beroendefil för projektets källfiler till header-filer. Detta är en egenskap hos analysen av C- och C++-filer. I framtiden kan beroendefilen cachas och kommer att uppdateras automatiskt av analysatorn. Fördelen med commit-kontroll med hjälp av filanalysläget jämfört med inkremental analys är att man bara behöver cacha denna fil och inte objektfiler.

Allmänna principer för analys av pull request

Att analysera hela projektet tar ganska mycket tid, så det är meningsfullt att bara kontrollera en del av det. Problemet är att man måste separera nya filer från övriga filer i projektet.

Låt oss titta på ett exempel på ett commit-träd med två grenar:

Låt oss föreställa oss att commit A1 innehåller en tillräckligt stor mängd kod som redan har granskats. Tidigare gjorde vi en gren från commit A1 och ändrade några filer.

Ni har säkert märkt att efter A1 har det skett ytterligare två commits, men dessa var också sammanslagningar av andra grenar, eftersom vi inte commit:ar i master. Och nu har tiden kommit då hotfix är redo. Därför har det skapats en pull request för att slå samman B3 och A3.

Självklart skulle man kunna kontrollera hela resultatet av deras sammanslagning, men det skulle ta för lång tid och vara orimligt, eftersom endast några filer har ändrats. Därför är det effektivare att analysera endast de ändrade filerna.

För detta får vi skillnaden mellan grenarna, medan vi är i HEAD-grenen som vi vill slå ihop till master:

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

$MERGE_BASE vi kommer att gå igenom detta mer ingående senare. Saken är den att långt ifrån varje CI-tjänst tillhandahåller nödvändig information om basen för sammanslagning, så varje gång måste vi komma på nya sätt att få dessa data. Detta kommer att beskrivas mer detaljerat nedan i varje beskrivna webbtjänst.

Så vi har fått skillnaden mellan grenarna, eller mer specifikt — listan över filnamn som har ändrats. Nu behöver vi ge filen .pvs-pr.list (vi har omdirigerat utdata dit ovan) till analyzern:

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

Efter analysen måste vi konvertera loggfilen (PVS-Studio.log) till ett mer lättläst format:

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

Detta kommando kommer att skriva ut en lista över fel i stderr (standard utdataflöde för felmeddelanden).

Men vi behöver inte bara skriva ut fel, utan även meddela vår bygg- och testtjänst om förekomsten av problem. För detta har en flagga lagts till i konverteraren -W (—indicate-warnings). Om det finns minst en varning från analyzern, kommer återvändande koden för verktyget plog-converter att ändras till 2, vilket i sin tur meddelar CI-tjänsten om potentiella fel i pull request-filerna.

Travis CI

Konfigurationen görs i form av en fil .travis.yml. För bekvämlighetens skull rekommenderar jag att flytta allt till ett separat bash-skript med funktioner som kommer att anropas från filen .travis.yml (bash namn_på_skriptet.sh funktionsnamn).

Vi kommer att lägga till nödvändig kod i skriptet på bash, på så sätt får vi mer funktionalitet. I avsnittet install ska vi skriva följande:

install:
  - bash .travis.sh travis_install

Om du har haft några instruktioner, kan du flytta dem till skriptet och ta bort bindestrecken.

Vi öppnar filen .travis.sh och lägger till installationen av analyzern i funktionen 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 
}

Nu lägger vi till i avsnittet script kör analys:

script:
  - bash .travis.sh travis_script

Och i bash-skriptet:

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
}

Denna kod ska köras efter att projektet har byggts, till exempel om du har en byggning med CMake:

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

Det blir så här:

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
}

Du har antagligen redan noterat de angivna miljövariablerna $TRAVIS_PULL_REQUEST och $TRAVIS_BRANCH. Travis CI deklarerar dem automatiskt:

• $TRAVIS_PULL_REQUEST innehåller numret på pull requesten eller false, om det är en vanlig gren;
• $TRAVIS_REPO_SLUG innehåller namnet på projektets repository.

Algoritmen för denna funktion:

Travis CI reagerar på returkoder, så förekomsten av varningar kommer att indikera för tjänsten att markera commit som innehållande fel.

Och nu låt oss ta en närmare titt på denna kodrad:

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

Poängen är att Travis CI automatiskt gör sammanslagningar av grenar under analysen av pull requests:

Därför analyserar vi A4, inte B3->A3. På grund av denna egenskap behöver vi beräkna skillnaden med A3, vilket just är toppen av grenen från origin.

Det finns en viktig detalj kvar — cache av beroenden i huvudfilsskäl från de kompilationsenheter som översätts (*.c, *.cc, *.cpp osv.). Dessa beroenden beräknas av analysatorn vid första körningen i filkolläge och sparas sedan i katalogen .PVS-Studio. Travis CI möjliggör cachning av mappar, så vi sparar data från katalogen .PVS-Studio/:

cache:
  directories:
    - .PVS-Studio/

Denna kod måste läggas till i filen .travis.yml. Denna katalog lagrar olika data som samlas in efter analysen, vilket väsentligt snabbar upp efterföljande körningar av filanalyslistan eller inkrementell analys. Om detta inte görs, kommer analysatorn faktiskt att analysera alla filer varje gång.

Buddy

Precis som Travis CI, Buddy möjliggör automatiserad byggnation och testning av projekt som lagras på GitHub. Till skillnad från Travis CI, konfigureras det i webbgränssnittet (bash-stöd finns), så det är inte nödvändigt att lagra konfigurationsfiler i projektet.

Först måste vi lägga till en ny åtgärd i bygglinjen:

Vi anger kompilatorn som användes för att bygga projektet. Observera dockerbehållaren som är installerad i denna åtgärd. Till exempel, för GCC finns det en speciell behållare:

Nu installerar vi PVS-Studio och nödvändiga verktyg:

Lägg till följande rader i redigeraren:

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

Nu går vi till fliken Run (den första ikonen) och lägger till följande kod i det angivna redigeringsfältet:

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

Om du har läst avsnittet om Travs-CI, så är denna kod redan bekant för dig, men nu har ett nytt steg tillkommit:

Det handlar om att vi nu analyserar inte resultatet av sammanslagningen, utan HEAD på den gren som pull requesten görs från:

Därför befinner vi oss i ett hypotetiskt commit B3 och vi behöver få skillnaden med 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

För att fastställa A3 använder vi GitHub API:

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

Vi använde följande variabler som tillhandahålls av Buddy:

• $BUDDY_EXECUTION_PULL_REQEUST_NO – numret på pull requesten;
• $BUDDY_REPO_SLUG – en kombination av användarnamn och repository (t.ex. max/test).

Nu sparar vi ändringarna med hjälp av knappen nedan och aktiverar analysen av pull request:

Till skillnad från Travis CI behöver vi inte specificera .pvs-studio för caching, eftersom Buddy automatiskt cacherar alla filer för efterföljande körningar. Det återstår bara en sak — att spara inloggningen och lösenordet för PVS-Studio i Buddy. När ändringarna sparas kommer vi tillbaka till Pipeline. Vi behöver gå till inställningarna för variabler och lägga till inloggning och nyckel för PVS-Studio:

Efter detta kommer en ny pull request eller commit att starta en kontroll. Om commiten innehåller fel kommer Buddy att påpeka detta på sidan för pull request.

AppVeyor

Inställningen av AppVeyor liknar Buddy, eftersom allt sker i webgränssnittet och det inte behövs att lägga till en fil *.yml i projektets repository.

Gå till fliken Inställningar i projektöversikten:

Rulla ner på sidan och aktivera cachning för pull request-byggnader:

Nu går vi till fliken Miljö, där vi anger bild för byggandet och nödvändiga miljövariabler:

Om du har läst de föregående avsnitten är du redan bekant med dessa två variabler — PVS_KEY och PVS_USERNAME. Om inte, påminner jag dig om att de behövs för att verifiera licensen för PVS-Studio-analysatorn. Vi kommer att träffa dem igen i Bash-skripten.

Längst ner på samma sida anger vi en mapp för caching:

Om vi inte gör detta kommer vi att analysera hela projektet istället för ett par filer, men få output baserat på de angivna filerna. Därför är det viktigt att ange rätt katalognamn.

Nu är det dags för skriptet för kontroll. Vi öppnar fliken Tester och väljer Skript:

I detta formulär behöver vi klistra in följande kod:

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

Låt oss titta närmare på den följande delen av koden:

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

Att tilldela värdet av kommandot pwd till en variabel som bör lagra detta värde som standard kan verka konstigt vid första anblick, men jag ska förklara det nu.

När jag satte upp analyzern i AppVeyor stötte jag på ett extremt märkligt beteende hos analyzern. Å ena sidan fungerade allt korrekt, men analysen startade aldrig. Jag spenderade mycket tid på att inse att vi var i katalogen /home/appveyor/projects/testcalc/, medan analyzern var övertygad om att vi var i /opt/appveyor/build-agent/. Då insåg jag att variabeln $PWD ljuger lite grann. Därför uppdaterade jag dess värde manuellt innan jag startade analysen.

Och sedan är det som vanligt:

Låt oss nu titta på nästa 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"`

Här får vi skillnaden mellan de grenar som en pull request är deklarerad för. För detta behöver vi följande miljövariabler:

• $APPVEYOR_PULL_REQUEST_NUMBER — numret på pull requesten;
• $APPVEYOR_REPO_NAME — användarnamn och projektnamn.

Slutsats

Självklart har vi inte granskat alla möjliga tjänster för kontinuerlig integrering, men de har alla en extremt liknande arbetsspecifikation. Med undantag för caching, gör varje tjänst sin "egen cykel", så det är alltid olika.

Någonstans, som i Travis-CI, krävs några rader kod och cache fungerar felfritt; någonstans, som i AppVeyor, måste du bara ange mappen i inställningarna; men någonstans måste du skapa unika nycklar och försöka övertyga systemet att ge dig möjlighet att åsidosätta den cachade delen. Så, om du vill ställa in analys av pull requests på en tjänst för kontinuerlig integrering som inte diskuterades ovan, se först till att du inte får problem med cache.

Tack för att du lyssnade. Om något inte fungerar, tveka inte att skriva till oss på supporten. Vi hjälper gärna till.

Om du vill dela denna artikel med en engelsktalande publik, vänligen använd länken till översättningen: Maxim Zvyagintsev. Analys av commits och pull requests i Travis CI, Buddy och AppVeyor med hjälp av PVS-Studio.

Källa: habr.com