🥇 Ontleding van commits en pull-versoeke in Travis CI, Buddy en AppVeyor met behulp van PVS-Studio

In die PVS-Studio-ontleder vir C- en C++-tale op Linux en macOS, vanaf weergawe 7.04, het 'n toetsopsie verskyn om die lys van gespesifiseerde lêers na te gaan. Deur die nuwe modus te gebruik, kan jy die ontleder instel om commits en pull-versoeke na te gaan. Hierdie artikel sal jou vertel hoe om die lys van veranderde lêers van 'n GitHub-projek op te stel in sulke gewilde CI (Continuous Integration) stelsels soos Travis CI, Buddy en AppVeyor.

Lêerlyskontrolemodus

PVS-ateljee is 'n hulpmiddel vir die identifisering van foute en potensiële kwesbaarhede in die bronkode van programme wat in C, C++, C# en Java geskryf is. Werk op 64-bis stelsels op Windows, Linux en macOS.

In weergawe PVS-Studio 7.04 vir Linux en macOS het 'n modus verskyn om die lys bronlêers na te gaan. Dit werk vir projekte waarvan die boustelsel jou toelaat om 'n lêer te genereer compile_commands.json. Dit is nodig vir die ontleder om inligting oor die samestelling van die gespesifiseerde lêers te onttrek. As jou boustelsel nie die generering van die compile_commands.json-lêer ondersteun nie, kan jy probeer om so 'n lêer te genereer met die hulpprogram Hou.

Die kontrolemodus vir lêerlys kan ook gebruik word saam met die spoorspoorlog van samestellerbekendstellings (pvs-studio-analyzer-spoor). Om dit te doen, sal jy eers 'n volledige bou van die projek moet uitvoer en dit opspoor sodat die ontleder volledige inligting oor die samestellingsparameters van alle lêers wat nagegaan word, versamel.

Hierdie opsie het egter 'n beduidende nadeel - jy sal óf 'n volledige bouspoor van die hele projek moet uitvoer elke keer as jy dit uitvoer, wat op sigself die idee weerspreek om 'n commit vinnig na te gaan. Of, as jy die spoorresultaat self kas, kan daaropvolgende lopies van die ontleder onvolledig wees as die afhanklikheidstruktuur van die bronlêers verander na die spoor (byvoorbeeld, 'n nuwe #include word by een van die bronlêers gevoeg).

Daarom beveel ons nie aan om die lêerlyskontrolemodus met die spoorlogboek te gebruik om commits of pull-versoeke na te gaan nie. As jy 'n inkrementele bou kan doen wanneer jy 'n commit nagaan, oorweeg dit om die modus te gebruik inkrementele analise.

Die lys bronlêers vir ontleding word in 'n tekslêer gestoor en deur die parameter na die ontleder deurgegee -S:

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

Hierdie lêer spesifiseer relatiewe of absolute paaie na lêers, en elke nuwe lêer moet op 'n nuwe lyn wees. Dit is aanvaarbaar om nie net lêername vir ontleding te spesifiseer nie, maar ook verskeie teks. Die ontleder sal sien dat dit nie 'n lêer is nie en sal die reël ignoreer. Dit kan nuttig wees om kommentaar te lewer as lêers met die hand gespesifiseer word. Dikwels sal 'n lys lêers egter tydens analise in CI gegenereer word, byvoorbeeld, dit kan lêers wees vanaf 'n commit of pull request.

Nou, met hierdie modus, kan jy vinnig nuwe kode nagaan voordat dit in die hoofontwikkelingstak kom. Om te verseker dat die skanderingstelsel reageer op ontlederwaarskuwings, die nut plog-omskakelaar vlag bygevoeg --dui-waarskuwings aan:

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

Met hierdie vlag sal die omskakelaar 'n nie-nul kode terugstuur as daar waarskuwings in die ontlederverslag is. Deur die terugstuurkode te gebruik, kan jy 'n precommit-haak-, commit- of trekversoek blokkeer, en die gegenereerde ontlederverslag kan vertoon, gedeel of per e-pos gestuur word.

Let wel. Wanneer jy eers begin om 'n lys lêers te ontleed, sal die hele projek ontleed word, want die ontleder moet 'n lêer van afhanklikhede van die projekbronlêers op die koplêers genereer. Dit is 'n kenmerk van die ontleding van C- en C++-lêers. In die toekoms kan die afhanklikheidslêer gekas word en dit sal outomaties deur die ontleder opgedateer word. Die voordeel van die kontrolering van commits wanneer die lêerlyskontrolemodus gebruik word bo die gebruik van inkrementele analise-modus, is dat jy net daardie lêer hoef te kas en nie die objeklêers nie.

Algemene beginsels van trekversoekanalise

Die ontleding van die hele projek neem baie tyd, so dit maak sin om net 'n sekere deel daarvan na te gaan. Die probleem is dat jy die nuwe lêers van die res van die projeklêers moet skei.

Kom ons kyk na 'n voorbeeld van 'n commit-boom met twee takke:

Kom ons stel ons daardie verbintenis voor A1 bevat 'n redelike groot hoeveelheid kode wat reeds getoets is. 'n Bietjie vroeër het ons 'n tak van die commit gemaak A1 en sommige lêers verander.

U het dit natuurlik agtergekom A1 nog twee verbintenisse het plaasgevind, maar dit was ook samesmeltings van ander takke, want ons verbind ons nie tot meester. En nou het die tyd aangebreek wanneer hotfix gereed. Daarom het 'n trekversoek vir die samesmelting verskyn B3 и A3.

Natuurlik sou dit moontlik wees om die hele resultaat van hul samesmelting na te gaan, maar dit sou te tydrowend en ongeregverdig wees, aangesien slegs 'n paar lêers verander is. Daarom is dit meer doeltreffend om slegs die veranderde te ontleed.

Om dit te doen, kry ons die verskil tussen die takke, in die HOOF van die tak waaruit ons in meester wil saamsmelt:

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

$MERGE_BASE ons sal later in detail daarna kyk. Die feit is dat nie elke CI-diens die nodige inligting oor die databasis verskaf vir samesmelting nie, so elke keer moet jy met nuwe maniere vorendag kom om hierdie data te bekom. Dit sal hieronder in elk van die beskryfde webdienste in detail beskryf word.

So, ons het die verskil tussen die takke, of liewer, 'n lys van lêername wat verander is. Nou moet ons die lêer gee .pvs-pr.lys (ons het die uitvoer hierbo herlei) na die ontleder:

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

Na ontleding moet ons die loglêer (PVS-Studio.log) omskep in 'n maklik leesbare formaat:

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

Hierdie opdrag sal die foute in lys stderr (standaard foutboodskap uitset).

Nou eers moet ons nie net foute vertoon nie, maar ook ons diens vir montering en toetsing inlig oor die teenwoordigheid van probleme. Vir hierdie doel is 'n vlag by die omskakelaar gevoeg -W (--dui-waarskuwings aan). As daar ten minste een ontlederwaarskuwing is, gee die hulpprogram kode terug plog-omskakelaar sal verander na 2, wat op sy beurt die CI-diens sal inlig oor die teenwoordigheid van potensiële foute in die trekversoeklêers.

Travis C.I.

Die konfigurasie word as 'n lêer gemaak .travis.yml. Gerieflik raai ek u aan om alles in 'n aparte bash-skrif te plaas met funksies wat vanaf die lêer geroep sal word .travis.yml (bash script_name.sh funksienaam).

Ons sal die nodige kode by die skrif voeg by bash, op hierdie manier sal ons meer funksionaliteit kry. In afdeling installeer kom ons skryf die volgende:

install:
  - bash .travis.sh travis_install

As jy enige instruksies gehad het, kan jy dit na die skrif oordra en die koppeltekens verwyder.

Kom ons maak die lêer oop .travis.sh en voeg die ontlederinstelling by die funksie 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 
}

Kom ons voeg nou by die afdeling script loop analise:

script:
  - bash .travis.sh travis_script

En in die bash script:

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
}

Hierdie kode moet uitgevoer word nadat die projek gebou is, byvoorbeeld as jy 'n bou op CMake gehad het:

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

Dit sal so uitdraai:

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
}

Jy het waarskynlik reeds hierdie omgewingsveranderlikes opgemerk $TRAVIS_PULL_REQUEST и $TRAVIS_BRANCH. Travis CI verklaar hulle onafhanklik:

$TRAVIS_PULL_REQUEST stoor die trekversoeknommer of valse, as dit 'n gewone tak is;
$TRAVIS_REPO_SLUG stoor die naam van die projekbewaarplek.

Die algoritme vir hierdie funksie:

Travis CI reageer op terugstuurkodes, so die teenwoordigheid van waarskuwings sal die diens vertel om die commit te merk as wat foute bevat.

Kom ons kyk nou nader na hierdie reël kode:

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

Die feit is dat Travis CI outomaties takke saamsmelt terwyl 'n trekversoek ontleed word:

Daarom ontleed ons A4en nie B3->A3. As gevolg van hierdie kenmerk, moet ons die verskil bereken met A3, wat presies die bokant van die tak van is oorsprong.

Daar is een belangrike detail oor - die kas van die afhanklikhede van koplêers op saamgestelde vertaaleenhede (*.c, *.cc, *.cpp, ens.). Die ontleder bereken hierdie afhanklikhede wanneer dit die eerste keer geloods word in die modus om 'n lys lêers na te gaan en stoor dit dan in die .PVS-Studio-gids. Travis CI laat jou toe om dopgehou te kas, so ons sal die gidsdata stoor .PVS-Studio/:

cache:
  directories:
    - .PVS-Studio/

Hierdie kode moet by die lêer gevoeg word .travis.yml. Hierdie gids stoor verskeie data wat na ontleding ingesamel is, wat die daaropvolgende lopies van lêerlysanalise of inkrementele analise aansienlik sal bespoedig. As dit nie gedoen word nie, sal die ontleder elke keer eintlik alle lêers analiseer.

Buddy

Soos Travis CI, Buddy bied die vermoë om projekte wat op GitHub gestoor is, outomaties te bou en te toets. Anders as Travis CI, is dit in die webkoppelvlak gekonfigureer (bash-ondersteuning is beskikbaar), so dit is nie nodig om konfigurasielêers in die projek te stoor nie.

Eerstens moet ons 'n nuwe aksie by die monteerlyn voeg:

Kom ons dui die samesteller aan wat gebruik is om die projek te bou. Let op die koppelaarhouer wat in hierdie aksie geïnstalleer is. Daar is byvoorbeeld 'n spesiale houer vir GCC:

Kom ons installeer nou PVS-Studio en die nodige nutsprogramme:

Kom ons voeg die volgende reëls by die redigeerder:

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

Kom ons gaan nou na die Run-oortjie (eerste ikoon) en voeg die volgende kode by die ooreenstemmende redigeerderveld:

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 jy die gedeelte oor Travs-CI lees, dan is hierdie kode reeds aan jou bekend, maar nou is daar 'n nuwe stadium:

Die feit is dat ons nou nie die resultaat van die samesmelting ontleed nie, maar die HOOF van die tak waaruit die trekversoek gedoen word:

Ons is dus in 'n voorwaardelike verbintenis B3 en ons moet die verskil van kry 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

Te bepaal A3 Kom ons gebruik die GitHub API:

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

Ons het die volgende veranderlikes gebruik wat Buddy verskaf:

$BUDDY_EXECUTION_PULL_REQEUST_NO — trek versoeknommer;
$BUDDY_REPO_SLUG - 'n kombinasie van gebruikersnaam en bewaarplek (byvoorbeeld maks/toets).

Kom ons stoor nou die veranderinge met die knoppie hieronder en aktiveer ontleding van die trekversoek:

Anders as Travis CI, hoef ons nie te spesifiseer nie .pvs-ateljee vir cache, aangesien Buddy outomaties alle lêers kas vir daaropvolgende bekendstellings. Daarom is die laaste ding wat oorbly om die login en wagwoord vir PVS-Studio in Buddy te stoor. Nadat ons die veranderinge gestoor het, sal ons teruggeneem word na Pyplyn. Ons moet voortgaan met die opstel van veranderlikes en die byvoeging van 'n aanmelding en sleutel vir PVS-Studio:

Hierna sal die verskyning van 'n nuwe trekversoek of commit die hersiening aktiveer. As 'n commit foute bevat, sal Buddy dit op die trekversoekbladsy aandui.

AppVeyor

Die opstel van AppVeyor is soortgelyk aan Buddy, aangesien alles in die webkoppelvlak gebeur en dit nie nodig is om 'n *.yml-lêer by die projekbewaarplek te voeg nie.

Kom ons gaan na die Instellings-oortjie in die projekoorsig:

Kom ons blaai af op hierdie bladsy en aktiveer kasbesparing vir die insameling van trekversoeke:

Kom ons gaan nou na die Omgewing-oortjie, waar ons die beeld vir samestelling en die nodige omgewingsveranderlikes spesifiseer:

As jy die vorige afdelings gelees het, is jy baie vertroud met hierdie twee veranderlikes − PVS_KEY и PVS_USERNAME. Indien nie, laat ek u daaraan herinner dat dit nodig is om die lisensie van die PVS-Studio-ontleder te verifieer. Ons sal hulle in die toekoms weer in Bash-skrifte sien.

Op dieselfde bladsy hieronder dui ons die gids vir kas aan:

As ons dit nie doen nie, sal ons die hele projek analiseer in plaas van 'n paar lêers, maar ons sal die uitvoer van die gespesifiseerde lêers kry. Daarom is dit belangrik om die korrekte gidsnaam in te voer.

Nou is dit tyd vir die draaiboek om te toets. Maak die toetse-oortjie oop en kies Skrip:

Jy moet die volgende kode in hierdie vorm plak:

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

Kom ons let op die volgende deel van die kode:

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 taamlik spesifieke toewysing van die waarde van die pwd-opdrag aan 'n veranderlike wat hierdie verstekwaarde moet stoor, lyk met die eerste oogopslag vreemd, maar ek sal alles nou verduidelik.

Terwyl ek die ontleder in AppVeyor opgestel het, het ek uiters vreemde gedrag van die ontleder teëgekom. Aan die een kant het alles reg gewerk, maar die ontleding het nie begin nie. Ek het baie tyd spandeer om te sien dat ons in die /home/appveyor/projects/testcalc/-gids is, en die ontleder is seker dat ons in /opt/appveyor/build-agent/ is. Toe besef ek dat die $PWD veranderlike 'n bietjie lieg. Om hierdie rede het ek die waarde daarvan handmatig opgedateer voordat ek met die ontleding begin het.

En dan is alles soos voorheen:

Oorweeg nou die volgende 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"`

Daarin kry ons die verskil tussen die takke waaroor die trekversoek verklaar word. Om dit te doen het ons die volgende omgewingsveranderlikes nodig:

$APPVEYOR_PULL_REQUEST_NUMBER — trek versoeknommer;
$APPVEYOR_REPO_NAME - gebruikernaam en projekbewaarplek.

Gevolgtrekking

Natuurlik het ons nie al die moontlike deurlopende integrasiedienste oorweeg nie, maar hulle het almal uiters soortgelyke bedryfspesifikasies aan mekaar. Met die uitsondering van caching, maak elke diens sy eie "fiets", so alles is altyd anders.

Iewers, soos in Travis-CI, werk 'n paar reëls kode en caching foutloos; iewers, soos in AppVeyor, hoef jy net die gids in die instellings te spesifiseer; maar iewers moet jy unieke sleutels skep en probeer om die stelsel te oortuig om jou die geleentheid te gee om die kasfragment te oorskryf. As jy dus ontleding van trekversoeke op 'n deurlopende integrasiediens wil opstel wat nie hierbo bespreek is nie, maak dan eers seker dat jy nie probleme met caching sal hê nie.

Dankie vir jou aandag. As iets nie uitwerk nie, skryf gerus vir ons by ondersteuning. Ons sal raad gee en help.

As jy hierdie artikel met 'n Engelssprekende gehoor wil deel, gebruik asseblief die vertaalskakel: Maxim Zvyagintsev. Ontleding van commits en pull-versoeke in Travis CI, Buddy en AppVeyor met behulp van PVS-Studio.

Bron: will.com

Ontleding van commits en pull-versoeke in Travis CI, Buddy en AppVeyor met behulp van PVS-Studio