🥇 Analyse fan commits en pull-oanfragen yn Travis CI, Buddy en AppVeyor mei PVS-Studio

Yn 'e PVS-Studio-analyzer foar C- en C++-talen op Linux en macOS, begjinnend fan ferzje 7.04, is in testopsje ferskynde om de list mei oantsjutte bestannen te kontrolearjen. Mei de nije modus kinne jo de analysator ynstelle om commits te kontrolearjen en oanfragen te lûken. Dit artikel sil jo fertelle hoe't jo de list mei feroare bestannen fan in GitHub-projekt kontrolearje kinne yn sokke populêre CI-systemen (Continuous Integration) lykas Travis CI, Buddy en AppVeyor.

Bestânslist kontrolearjen modus

PVS-Studio is in ark foar it identifisearjen fan flaters en potinsjele kwetsberens yn 'e boarnekoade fan programma's skreaun yn C, C++, C# en Java. Wurket op 64-bit systemen op Windows, Linux en macOS.

Yn ferzje PVS-Studio 7.04 foar Linux en macOS is in modus ferskynd foar it kontrolearjen fan de list mei boarnebestannen. Dit wurket foar projekten wêrfan it bousysteem jo in bestân kin generearje compile_commands.json. It is nedich foar de analysator om ynformaasje oer de kompilaasje fan 'e opjûne bestannen te ekstrahearjen. As jo bousysteem it generearjen fan it compile_commands.json-bestân net stipet, kinne jo besykje sa'n bestân te generearjen mei it helpprogramma Bear.

Ek kin de kontrolemodus foar bestânlist wurde brûkt tegearre mei it trace-trace-log fan kompilerlansearrings (pvs-studio-analyzer trace). Om dit te dwaan, moatte jo earst in folsleine bou fan it projekt útfiere en it folgje, sadat de analysator folsleine ynformaasje sammelt oer de kompilaasjeparameters fan alle kontroleare bestannen.

Dizze opsje hat lykwols in signifikant neidiel - jo moatte elke kear as jo it útfiere in folsleine build-spoar fan it heule projekt útfiere, wat op himsels it idee tsjinsprekt om in commit fluch te kontrolearjen. Of, as jo it spoarresultaat sels yn 'e cache bewarje, kinne folgjende runs fan' e analysator ûnfolslein wêze as de ôfhinklikensstruktuer fan 'e boarnebestannen nei it spoar feroaret (bygelyks in nije #include wurdt tafoege oan ien fan 'e boarnebestannen).

Dêrom riede wy net oan om de kontrôlemodus foar bestânlist te brûken mei it spoarlogboek om commits te kontrolearjen of oanfragen te lûken. As jo in inkrementele build kinne dwaan by it kontrolearjen fan in commit, beskôgje dan it brûken fan de modus inkrementele analyze.

De list mei boarnebestannen foar analyse wurdt bewarre yn in tekstbestân en trochjûn oan de analysator mei de parameter -S:

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

Dizze triem spesifisearret relative of absolute paden nei triemmen, en elke nije triem moat op in nije rigel stean. It is akseptabel om net allinich bestânsnammen foar analyse op te jaan, mar ek ferskate tekst. De analysator sil sjen dat dit gjin bestân is en sil de line negearje. Dit kin nuttich wêze foar kommentaar as bestannen manuell wurde opjûn. Faak wurdt lykwols in list mei bestannen generearre tidens analyse yn CI, dit kinne bygelyks bestannen wêze fan in commit- of pull-oanfraach.

No, mei dizze modus, kinne jo nije koade fluch kontrolearje foardat it yn 'e haadûntwikkelingstak komt. Om derfoar te soargjen dat it skennensysteem reagearret op warskôgings fan analysator, it nut plog-konverter flagge tafoege --oantsjutte-warskôgings:

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

Mei dizze flagge sil de converter in net-nulkoade weromjaan as der warskôgings binne yn it analysatorrapport. Mei help fan de werom koade, kinne jo blokkearje in precommit hook, commit, of pull fersyk, en it oanmakke analysator rapport kin wurde werjûn, dield, of stjoerd troch e-mail.

Noat. As jo earst begjinne mei it analysearjen fan in list mei bestannen, sil it heule projekt wurde analysearre, om't de analysator moat in bestân generearje fan ôfhinklikens fan 'e projektboarnebestannen op' e koptekstbestannen. Dit is in funksje fan it analysearjen fan C- en C++-bestannen. Yn 'e takomst kin it ôfhinklikheidsbestân yn cache wurde en it sil automatysk bywurke wurde troch de analysator. It foardiel fan it kontrolearjen fan commits by it brûken fan bestânlistkontrôlemodus oer it brûken fan inkrementele analysemodus is dat jo allinich dat bestân hoege te cache en net de objektbestannen.

Algemiene prinsipes fan pull-oanfraachanalyse

It analysearjen fan it hiele projekt nimt in protte tiid, dus it makket sin om mar in bepaald diel dêrfan te kontrolearjen. It probleem is dat jo de nije bestannen moatte skiede fan 'e rest fan' e projektbestannen.

Litte wy nei in foarbyld sjen fan in commitbeam mei twa tûken:

Lit ús dy ynset foarstelle A1 befettet in frij grutte hoemannichte koade dat is al hifke. Efkes earder makken wy in tûke fan de commit A1 en feroare guon triemmen.

Jo, fansels, opfallen dat na A1 der binne noch twa commits bard, mar dit wiene ek fúzjes fan oare filialen, om't wy ús net ynsette foar master. En no is de tiid kommen wannear hotfix klear. Dêrom ferskynde in pull-fersyk foar de fúzje B3 и A3.

Fansels soe it mooglik wêze om it folsleine resultaat fan har fúzje te kontrolearjen, mar dit soe te tiidslinend en ûnrjochtfeardich wêze, om't mar in pear triemmen feroare binne. Dêrom is it effisjinter om allinich de feroare te analysearjen.

Om dit te dwaan, krije wy it ferskil tusken de tûken, yn 'e HEAD fan' e tûke wêrfan wy wolle fusearje yn master:

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

$MERGE_BASE wy sjogge it letter yn detail. It feit is dat net elke CI-tsjinst de nedige ynformaasje jout oer de databank foar gearfoeging, dus elke kear moatte jo nije manieren komme om dizze gegevens te krijen. Dit sil hjirûnder yn detail beskreaun wurde yn elk fan 'e beskreaune webtsjinsten.

Dat, wy krigen it ferskil tusken de tûken, of leaver, in list mei triemnammen dy't waarden feroare. No moatte wy it bestân jaan .pvs-pr.list (wy hawwe de útfier hjirboppe omlaat) nei de analysator:

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

Nei analyse moatte wy it logbestân (PVS-Studio.log) konvertearje yn in maklik te lêzen formaat:

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

Dit kommando sil de flaters yn listje stderr (standert flater berjocht útfier).

Allinnich no moatte wy net allinich flaters werjaan, mar ek ús tsjinst foar montage en testen ynformearje oer de oanwêzigens fan problemen. Foar dit doel waard in flagge tafoege oan de converter -W (--oantsjutte-warskôgings). As d'r op syn minst ien warskôging foar analysator is, komt de koade werom plog-konverter sil feroarje nei 2, dy't op syn beurt de CI-tsjinst sil ynformearje oer de oanwêzigens fan potinsjele flaters yn 'e pull-fersykbestannen.

Travis C.I.

De konfiguraasje wurdt makke as in triem .travis.yml. Foar it gemak advisearje ik jo om alles yn in apart bash-skript te setten mei funksjes dy't sille wurde neamd út it bestân .travis.yml (bash script_name.sh function_name).

Wy sille tafoegje de nedige koade oan it skript by bash, op dizze manier sille wy mear funksjonaliteit krije. Yn seksje ynstallearje litte wy it folgjende skriuwe:

install:
  - bash .travis.sh travis_install

As jo instruksjes hawwe, kinne jo se oerdrage yn it skript, troch de koppeltekens te ferwiderjen.

Litte wy it bestân iepenje .travis.sh en foegje de analyzerynstelling ta oan 'e funksje 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 
}

Litte wy no tafoegje oan 'e seksje skrift run analyze:

script:
  - bash .travis.sh travis_script

En yn it 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
}

Dizze koade moat wurde útfierd nei it bouwen fan it projekt, bygelyks as jo in build hawwe op CMake:

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

It sil sa útkomme:

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
}

Jo hawwe dizze omjouwingsfariabelen wierskynlik al opmurken $TRAVIS_PULL_REQUEST и $TRAVIS_BRANCH. Travis CI ferklearret se ûnôfhinklik:

$TRAVIS_PULL_REQUEST bewarret de pull fersyk nûmer of falsk, as dit in gewoane tûke is;
$TRAVIS_REPO_SLUG slaat de namme fan it projektopslach op.

It algoritme foar dizze funksje:

Travis CI reagearret op weromkoades, sadat de oanwêzigens fan warskôgingen de tsjinst sil fertelle om de commit te markearjen as befetsjende flaters.

Litte wy no in tichterby besjen op dizze rigel fan koade:

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

It feit is dat Travis CI automatysk tûken fusearret by it analysearjen fan in pull-fersyk:

Dêrom analysearje wy A4, en net B3->A3. Fanwegen dizze funksje, wy moatte berekkenje it ferskil mei A3, dat is krekt de top fan 'e tûke út oarsprong.

D'r is ien wichtich detail oerbleaun - it cache fan de ôfhinklikens fan koptekstbestannen op kompilearre oersettingseenheden (*.c, *.cc, *.cpp, ensfh.). De analysator berekkent dizze ôfhinklikens as it earst wurdt lansearre yn 'e modus fan it kontrolearjen fan in list mei bestannen en bewarret se dan yn' e .PVS-Studio-map. Travis CI lit jo mappen yn cache bewarje, sadat wy de mapgegevens bewarje .PVS-Studio/:

cache:
  directories:
    - .PVS-Studio/

Dizze koade moat wurde tafoege oan it bestân .travis.yml. Dizze map bewarret ferskate gegevens sammele nei analyze, wat de folgjende runs fan analyse fan bestânslist as inkrementele analyze signifikant sil fersnelle. As dit net dien wurdt, dan sil de analysator elke kear alle bestannen feitlik analysearje.

Buddy

Lykas Travis CI, Buddy biedt de mooglikheid om projekten op GitHub automatysk te bouwen en te testen. Oars as Travis CI, is it konfigureare yn 'e webynterface (bash-stipe is beskikber), dus it is net nedich om konfiguraasjebestannen yn it projekt op te slaan.

Alderearst moatte wy in nije aksje tafoegje oan 'e gearkomste line:

Litte wy de kompilator oanjaan dy't waard brûkt om it projekt te bouwen. Notysje de docker-kontener dy't yn dizze aksje is ynstalleare. Bygelyks, d'r is in spesjale kontener foar GCC:

Litte wy no PVS-Studio en de nedige nutsfoarsjenningen ynstallearje:

Litte wy de folgjende rigels tafoegje oan de bewurker:

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

Litte wy no nei it ljepblêd Run gean (earste byldkaike) en de folgjende koade tafoegje oan it korrespondearjende bewurkerfjild:

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

As jo de seksje oer Travs-CI lêze, dan is dizze koade jo al bekend, mar no is d'r in nije poadium:

It feit is dat wy no net it resultaat fan 'e fúzje analysearje, mar de HEAD fan' e tûke wêrfan it pull-fersyk wurdt makke:

Sa binne wy yn in betingst commit B3 en wy moatte krije it ferskil út 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

Foar it bepalen A3 Litte wy de GitHub API brûke:

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

Wy brûkten de folgjende fariabelen dy't Buddy leveret:

$BUDDY_EXECUTION_PULL_REQEUST_NO - pull fersyk nûmer;
$BUDDY_REPO_SLUG - in kombinaasje fan brûkersnamme en repository (bygelyks max/test).

Litte wy no de wizigingen opslaan mei de knop hjirûnder en analyse fan it pull-fersyk ynskeakelje:

Oars as Travis CI, hoege wy net oan te jaan .pvs-studio foar caching, sûnt Buddy automatysk cache alle triemmen foar folgjende lansearringen. Dêrom is it lêste wat oerbleaun is om de oanmelding en wachtwurd foar PVS-Studio yn Buddy te bewarjen. Nei it bewarjen fan de wizigingen, wurde wy werombrocht nei Pipeline. Wy moatte trochgean mei it ynstellen fan fariabelen en it tafoegjen fan in oanmelding en kaai foar PVS-Studio:

Hjirnei sil it ferskinen fan in nij pull-fersyk of commit de resinsje trigger. As in commit flaters befettet, sil Buddy dit oanjaan op 'e pull-fersykside.

AppVeyor

It ynstellen fan AppVeyor is te fergelykjen mei Buddy, om't alles bart yn 'e webynterface en it is net nedich om in *.yml-bestân ta te foegjen oan it projektrepository.

Litte wy nei it ljepblêd Ynstellings gean yn it projektoersjoch:

Litte wy dizze side nei ûnderen rôlje en cache-opslach ynskeakelje foar it sammeljen fan pull-oanfragen:

Litte wy no nei it ljepblêd Omjouwing gean, wêr't wy de ôfbylding foar assemblage en de nedige omjouwingsfariabelen spesifisearje:

As jo de foarige seksjes lêzen hawwe, binne jo tige bekend mei dizze twa fariabelen - PVS_KEY и PVS_USERNAME. As net, lit my jo herinnerje dat se nedich binne om de lisinsje fan 'e PVS-Studio-analyzer te ferifiearjen. Wy sille se yn 'e takomst wer sjen yn Bash-skripts.

Op deselde side hjirûnder jouwe wy de map foar caching oan:

As wy dit net dogge, sille wy it hiele projekt analysearje ynstee fan in pear bestannen, mar wy sille de útfier krije fan 'e oantsjutte bestannen. Dêrom is it wichtich om de juste mapnamme yn te fieren.

No is it tiid foar it skript om te testen. Iepenje de ljepper Tests en selektearje Skript:

Jo moatte de folgjende koade yn dit formulier plakke:

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

Litte wy omtinken jaan oan it folgjende diel fan 'e koade:

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

De frijwat spesifike tawizing fan de wearde fan it pwd-kommando oan in fariabele dy't dizze standertwearde opslaan moat liket op it earste each nuver, lykwols sil ik no alles útlizze.

By it ynstellen fan de analysator yn AppVeyor, kaam ik ekstreem frjemd gedrach fan 'e analysator tsjin. Oan 'e iene kant wurke alles goed, mar de analyze begon net. Ik haw in protte tiid trochbrocht om te merken dat wy yn 'e map /home/appveyor/projects/testcalc/ binne, en de analysator is wis dat wy yn /opt/appveyor/build-agent/ binne. Doe realisearre ik dat de fariabele $PWD in bytsje lei. Om dizze reden haw ik de wearde manuell bywurke foardat ik de analyse begon.

En dan is alles as earder:

Besjoch no it folgjende fragmint:

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

Dêryn krije wy it ferskil tusken de tûken dêr't it pull-fersyk oer ferklearre wurdt. Om dit te dwaan hawwe wy de folgjende omjouwingsfariabelen nedich:

$ APPVEYOR_PULL_REQUEST_NUMBER - pull request number;
$APPVEYOR_REPO_NAME - brûkersnamme en projektrepository.

konklúzje

Fansels hawwe wy net alle mooglike tsjinsten foar trochgeande yntegraasje beskôge, se hawwe lykwols allegear ekstreem ferlykbere operearjende spesifikaasjes oan elkoar. Mei útsûndering fan caching makket elke tsjinst syn eigen "fyts", dus alles is altyd oars.

Earne, lykas yn Travis-CI, wurket in pear rigels koade en caching feilloos; earne, lykas yn AppVeyor, moatte jo gewoan de map opjaan yn 'e ynstellings; mar earne moatte jo unike kaaien meitsje en besykje it systeem te oertsjûgjen om jo de kâns te jaan om it cached fragmint te oerskriuwen. Dêrom, as jo analyse fan pull-oanfragen opstelle wolle op in trochgeande yntegraasjetsjinst dy't net hjirboppe besprutsen is, soargje dan earst derfoar dat jo gjin problemen hawwe mei caching.

Tank foar jo oandacht. As eat net slagget, fiel frij om te skriuwen nei ús op stypje. Wy sille advisearje en helpe.

As jo dit artikel wolle diele mei in Ingelsktalig publyk, brûk dan de oersettingskeppeling: Maxim Zvyagintsev. Analyse fan commits en pull-oanfragen yn Travis CI, Buddy en AppVeyor mei PVS-Studio.

Boarne: www.habr.com

Analyse fan commits en pull-oanfragen yn Travis CI, Buddy en AppVeyor mei PVS-Studio