🥇PVS-Studio erabiliz Travis CI, Buddy eta AppVeyor-en konpromisoen eta tira-eskaeren azterketa

7.04 bertsiotik hasita, C eta C++ lengoaietarako PVS-Studio analizatzaileak Linux eta macOS-en proba aukera bat du zehaztutako fitxategien zerrenda egiaztatzeko. Modu berria erabiliz, analizatzailea konfiguratu dezakezu konpromisoak eta tira eskaerak egiaztatzeko. Artikulu honek GitHub proiektuko fitxategien zerrenda egiaztatzea nola konfiguratu erakutsiko dizu CI (Etengabeko Integrazioa) sistema ezagunetan, hala nola Travis CI, Buddy eta AppVeyor.

Fitxategien zerrenda egiaztatzeko modua

PVS-Studioa C, C++, C# eta Javan idatzitako programen iturburu-kodean akatsak eta balizko ahuleziak detektatzeko tresna da. Windows, Linux eta macOS 64 biteko sistemetan funtzionatzen du.

Linux eta macOSentzako PVS-Studio 7.04 bertsioak iturburu-fitxategien zerrenda egiaztatzeko modua du. Honek eraikitze-sistemak fitxategi bat sortzeko aukera ematen duten proiektuetarako funtzionatzen du compile_commands.json. Beharrezkoa da analizatzaileak zehaztutako fitxategien konpilazioari buruzko informazioa ateratzeko. Zure eraikuntza-sistemak compile_commands.json fitxategia sortzea onartzen ez badu, erabilgarritasuna erabiliz fitxategi hori sortzen saia zaitezke. Bear.

Era berean, fitxategien zerrenda egiaztatzeko modua konpiladoreen exekuzioen traza-trazarekin batera erabil daiteke (pvs-studio-analyzer traza). Horretarako, lehenik eta behin proiektuaren eraikuntza osoa egin eta haren jarraipena egin beharko duzu, analizatzaileak egiaztatzen diren fitxategi guztien konpilazio-parametroei buruzko informazio osoa bil dezan.

Hala ere, aukera honek eragozpen esanguratsu bat du: proiektu osoaren eraikuntza-aztarna osoa egin beharko duzu abiarazte bakoitzean, eta horrek, berez, konpromiso azkarren egiaztapenaren ideia kontraesanean dago. Edo, trazaduraren emaitza bera cacheatzen baduzu, analizatzailearen ondorengo abiarazteak osatu gabe egon daitezke iturburu-fitxategiaren mendekotasun-egitura arrastoaren ondoren aldatzen bada (adibidez, #include berri bat gehitzen da iturburu-fitxategietako batean).

Hori dela eta, ez dugu gomendatzen fitxategi-zerrenda egiaztatzeko modua traza-erregistro batekin erabiltzea konpromisoak edo tira-eskaerak egiaztatzeko. Konpromiso bat egiaztatzean gehikuntza bat egin dezakezun kasuan, kontuan hartu modua erabiltzea analisi inkrementala.

Analisirako iturburu-fitxategien zerrenda testu-fitxategi batean gordetzen da eta analizatzailera pasatzen da parametroa erabiliz -S:

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

Fitxategi honek fitxategien bide erlatiboak edo absolutuak zehazten ditu, eta fitxategi berri bakoitzak lerro berri batean egon behar du. Aztertzeko fitxategien izenak ez ezik, hainbat testu ere zehaztea zilegi da. Analizatzaileak hau fitxategi bat ez dela ikusiko du eta lerroari ez dio jaramonik egingo. Hau erabilgarria izan daiteke iruzkinak egiteko fitxategiak eskuz zehazten badira. Hala ere, sarritan fitxategien zerrenda CI analizatzean sortuko da, esate baterako, konpromezu edo tira eskaera bateko fitxategiak.

Orain, modu hau erabiliz, kode berria azkar probatu dezakezu garapen adar nagusira sartu aurretik. Egiaztapen-sistemak analizatzaileen abisuei erreakziona diezaion, erabilgarritasuna plog-bihurgailua bandera gehitu da --adierazi-abisuak:

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

Bandera honekin, bihurgailuak zero ez den kode bat itzuliko du analizatzailearen txostenean abisurik badago. Itzulpen-kodea erabiliz, aurrekonpromisoa blokeatu dezakezu, konpromisoa edo tira eskaera, eta sortutako analizatzailearen txostena pantailan bistaratu, partekatu edo postaz bidali.

Ohar. Fitxategien zerrenda aztertzen hasten zarenean, proiektu osoa aztertuko da, izan ere analizatzaileak proiektuaren iturburu-fitxategien menpekotasunen fitxategi bat sortu behar du goiburuko fitxategietan. Hau C eta C++ fitxategiak analizatzeko ezaugarri bat da. Etorkizunean, mendekotasun fitxategia cachean gorde daiteke eta automatikoki eguneratuko du analizatzaileak. Fitxategi-zerrenda egiaztatzeko modua erabiltzean konpromezuak egiaztatzearen abantaila da analisi inkrementala erabiltzearen aldean fitxategi hori bakarrik gorde behar dela cachean, ez objektu-fitxategiak.

Tira-eskaeraren analisiaren printzipio orokorrak

Proiektu osoaren azterketak denbora asko behar du, beraz, zentzuzkoa da zatiren bat bakarrik egiaztatzea. Arazoa da fitxategi berriak proiektuko gainerako fitxategietatik bereizi behar dituzula.

Demagun bi adar dituen commit zuhaitz baten adibide bat:

Itxura dezagun konpromisoa hartzen duela A1 dagoeneko egiaztatu den kode kopuru handi samarra dauka. Pixka bat lehenago adar bat egin genuen konpromisotik A1 eta fitxategi batzuk aldatu ditu.

Noski, horretaz ohartu zinen ondoren A1 beste bi konpromiso zeuden, baina hauek ere beste adar batzuen fusioak ziren, ez dugulako konpromisorik hartzen master. Eta orain heldu da noiz hotfix prest. Hori dela eta, bateratze-eskaera bat agertu zen B3 и A3.

Jakina, posible izango litzateke haien bat-egitearen emaitza osoa egiaztatzeko, baina hori luzeegia eta justifikatu gabea izango litzateke, fitxategi gutxi batzuk bakarrik aldatu baitira. Horregatik, eraginkorragoa da aldatutakoak soilik aztertzea.

Horretarako, adarren arteko aldea lortzen dugu, maisuan batu nahi dugun adarraren BURUAN egonik:

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

$MERGE_BASE aurrerago aztertuko dugu zehatz-mehatz. Kontua da CI zerbitzu guztiek ez dutela bateratze-oinarriari buruzko beharrezko informazioa ematen, beraz, aldi bakoitzean datu horiek lortzeko modu berriak asmatu behar dituzu. Jarraian azalduko da deskribatutako web zerbitzu bakoitzean.

Beraz, adarren arteko aldea lortu dugu, edo hobeto esanda, aldatu diren fitxategi-izenen zerrenda. Orain fitxategia eman behar dugu .pvs-pr.zerrenda (goiko irteera bertara birbideratu dugu) analizatzailera:

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

Aztertu ondoren, log fitxategia (PVS-Studio.log) formatu irakurgarri batean bihurtu behar dugu:

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

Komando honek akatsak zerrendatuko ditu stderr (errore estandarra irteera korrontea).

Hemen bakarrik akatsak bistaratu ez ezik, gure zerbitzua muntatzeko eta probak egiteko arazoen presentziaz jakinarazi behar dugu. Horretarako, bandera bat gehitu zitzaion bihurgailuari -W (--adierazi-abisuak). Gutxienez analizatzailearen abisu bat badago, utilitatearen itzulera kodea plog-bihurgailua 2-ra aldatuko da, eta horrek, aldi berean, tira-eskaeraren fitxategietan akats potentzialak daudela jakinaraziko dio CI zerbitzuari.

Travis CI

Konfigurazioa fitxategi moduan egiten da .travis.yml. Erosotasuna lortzeko, dena bash script batean jartzea gomendatzen dizut fitxategitik deituko diren funtzioekin. .travis.yml (bash scriptname.sh funtzio_izena).

Beharrezko kodea gehituko diogu script-ari golpear, beraz, funtzionalitate gehiago lortuko dugu. atalean instalatzeko idatz ditzagun honako hau:

install:
  - bash .travis.sh travis_install

Argibiderik bazenuen, gidoira eraman ditzakezu marratxoak kenduz.

Ireki dezagun fitxategia .travis.sh eta gehitu analizatzailearen konfigurazioa funtzioari 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 
}

Orain gehitu gaitezen atala script exekutatu azterketa:

script:
  - bash .travis.sh travis_script

Eta bash gidoian:

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
}

Kode hau proiektua eraiki ondoren exekutatu behar da, adibidez, CMake eraikitze bat bazenuen:

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

Honela aterako da:

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
}

Ziurrenik dagoeneko zehaztutako ingurune-aldagaiak nabaritu dituzu. $TRAVIS_PULL_REQUEST и $TRAVIS_BRANCH. Travis CIk bere kabuz deklaratzen ditu:

$TRAVIS_PULL_REQUEST tira eskaeraren zenbakia gordetzen du, edo falseadar normala bada;
$TRAVIS_REPO_SLUG proiektuaren biltegiaren izena gordetzen du.

Funtzio honen algoritmoa:

Travis CIk itzulera-kodeei erantzuten die, beraz, abisuak egoteak zerbitzuari esango dio konpromisoa akats gisa markatzeko.

Ikus dezagun hurbilagotik kode-lerro hau:

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

Kontua da Travis CI-k adarrak automatikoki batzen dituela tira eskaera baten azterketan:

Hori dela eta, aztertzen dugu A4Eta ez B3->A3. Ezaugarri hau dela eta, aldea kalkulatu behar dugu A3, hau da, adarraren goialdea besterik ez da jatorria.

Xehetasun garrantzitsu bat geratzen da: goiburuko fitxategien mendekotasunak konpilatutako itzulpen-unitateetan gordetzea (*.c, *.cc, *.cpp, etab.). Analizatzaileak mendekotasun horiek kalkulatzen ditu fitxategien zerrenda egiaztatzeko moduan lehenengo abiaraztean eta gero .PVS-Studio direktorioan gordetzen ditu. Travis CI-k karpetak cachean gordetzeko aukera ematen du, beraz, direktorioko datuak gordeko ditugu .PVS-Studio/:

cache:
  directories:
    - .PVS-Studio/

Kode hau fitxategian gehitu behar da .travis.yml. Direktorio honek analisiaren ondoren bildutako hainbat datu gordetzen ditu, eta horrek nabarmen azkartuko ditu fitxategi-zerrenden azterketa edo analisi inkrementalaren ondorengo exekuzioak. Hori egiten ez bada, analizatzaileak fitxategi guztiak aztertuko ditu aldi bakoitzean.

Buddy

Travis C.I. bezala, Buddy GitHub-en gordetzen diren proiektuak automatikoki eraikitzeko eta probatzeko gaitasuna eskaintzen du. Travis CI ez bezala, web interfazean konfiguratuta dago (bash euskarria eskuragarri dago), beraz, ez dago proiektuan konfigurazio fitxategiak gorde beharrik.

Lehenik eta behin, ekintza berri bat gehitu behar dugu eraikuntza-lerroan:

Zehaztu proiektua eraikitzeko erabili den konpilatzailea. Kontuan izan jarduera honetan instalatuta dagoen docker edukiontzia. Adibidez, GCCrako edukiontzi berezi bat dago:

Orain instala ditzagun PVS-Studio eta beharrezko utilitateak:

Gehitu lerro hauek editorean:

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

Orain joan gaitezen Exekutatu fitxara (lehenengo ikonoa) eta gehitu kode hau dagokion editorearen eremuan:

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

Travs-CI-ri buruzko atala irakurri baduzu, kode hau ezaguna zaizu dagoeneko, baina orain urrats berri bat dago:

Kontua da orain ez dugula bategitearen emaitza aztertzen ari, tira eskaera egiten den adarraren BURUA baizik:

Beraz, baldintzapeko konpromisoan gaude B3 eta aldea lortu behar dugu 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

Zehazteko A3 Erabili dezagun GitHub APIa:

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

Buddy-k emandako aldagai hauek erabili ditugu:

$BUDDY_EXECUTION_PULL_REQEUST_NO - tira eskaera zenbakia;
$BUDDY_REPO_SLUG - erabiltzaile-izena eta biltegiaren konbinazioa (adibidez, max / test).

Orain gorde ditzagun aldaketak beheko botoia erabiliz eta gaitu tiratzeko eskaeraren azterketa:

Travis CI ez bezala, ez dugu zehaztu beharrik .pvs-estudioa cachean gordetzeko, Buddy-k fitxategi guztiak automatikoki gordetzen baititu ondorengo abiarazteko. Hori dela eta, geratzen den azken gauza PVS-Studiorako saioa eta pasahitza Buddy-n gordetzea da. Aldaketak gorde ondoren, Pipelinera itzuliko gara. Aldagaiak ezartzera joan eta PVS-Studiorako saioa eta gakoa gehitu behar ditugu:

Horren ondoren, tira-eskaera edo konpromiso berri bat agertzeak egiaztapen bat eragingo du. Konpromiso batek akatsak baditu, Buddy-k tira-eskaeraren orrian adieraziko du.

AppVeyor

AppVeyor konfiguratzea Buddyren antzekoa da, dena web-interfazean gertatzen baita eta ez baita beharrezkoa *.yml fitxategi bat gehitu proiektuaren biltegian.

Goazen Ezarpenak fitxara proiektuaren ikuspegi orokorrean:

Joan gaitezen orrialde honetan behera eta gaitu cache-a gordetzea tira-eskaerak eraikitzeko:

Orain Ingurune fitxara joan gaitezen, non eraiki beharreko irudia eta beharrezko ingurune-aldagaiak zehaztuko ditugu:

Aurreko atalak irakurri badituzu, oso ezagunak dituzu bi aldagai hauek − PVS_KEY и PVS_USERNAME. Hala ez bada, gogorarazten dizut beharrezkoak direla PVS-Studio analizatzailearen lizentzia egiaztatzeko. Etorkizunean, berriro ezagutuko ditugu Bash gidoietan.

Beheko orrialde berean, zehaztu cachean gordetzeko karpeta:

Hori egiten ez badugu, proiektu osoa aztertuko dugu fitxategi pare baten ordez, baina zehaztutako fitxategietan oinarritutako irteera lortuko dugu. Horregatik, garrantzitsua da direktorio-izen zuzena sartzea.

Orain gidoia probatzeko garaia da. Ireki Probak fitxa eta hautatu Script:

Itsatsi hurrengo kodea formulario honetan:

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

Ikus dezagun kodearen zati hau:

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

Lehen begiratuan balio lehenetsia gorde behar duen aldagai bati pwd komandoaren balioa esleitzea arraroa dirudi, hala ere, une batean dena azalduko dut.

Analizatzailea AppVeyor-en konfiguratzean, analizatzailearen portaera arraroa aurkitu nuen. Alde batetik, dena ondo funtzionatu zuen, baina analisia ez zen hasi. Denbora asko eman nuen ohartzen /home/appveyor/projects/testcalc/ direktorioan gaudela, eta analizatzaileak ziur dago /opt/appveyor/build-agent/-en gaudela. Orduan konturatu nintzen $PWD aldagaia gezur samarra dela. Horregatik, eskuz eguneratu nuen bere balioa analisia hasi aurretik.

Eta gero dena, lehen bezala:

Orain kontuan hartu hurrengo zatia:

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

Bertan, tira eskaera deklaratzen den adarren arteko aldea lortzen dugu. Horretarako, ingurune-aldagai hauek behar ditugu:

$APPVEYOR_PULL_REQUEST_NUMBER - atera eskaeraren zenbakia;
$APPVEYOR_REPO_NAME - erabiltzaile-izena eta proiektuaren biltegia.

Ondorioa

Jakina, ez ditugu kontuan hartu etengabeko integrazio-zerbitzu guztiak, hala ere, guztiek dute lan-zehaztasun oso antzekoak. Cachea izan ezik, zerbitzu bakoitzak bere “bizikleta” egiten du, beraz dena beti da ezberdina.

Nonbait, Travis-CI-n bezala, kode-lerro pare batek eta cacheak ezin hobeto funtzionatzen du; nonbait, AppVeyor-en bezala, ezarpenetan karpeta zehaztu besterik ez duzu behar; baina nonbait gako bereziak sortu eta sistema konbentzitzen saiatu behar duzu cacheko zatia gainidazteko aukera emateko. Hori dela eta, goian eztabaidatu ez den etengabeko integrazio-zerbitzu batean tira-eskaeraren azterketa konfiguratu nahi baduzu, lehenik eta behin ziurtatu ez duzula arazorik izango cachean gordetzeko.

Eskerrik asko zure arretagatik. Zerbaitek ondo ez badu, idatzi lasai hona laguntza. Aholkatu eta lagunduko dugu.

Artikulu hau ingelesez hitz egiten duen publiko batekin partekatu nahi baduzu, mesedez erabili itzulpen-esteka: Maxim Zvyagintsev. Travis CI, Buddy eta AppVeyor-en konpromisoen eta tira-eskaeren azterketa PVS-Studio erabiliz.

Iturria: www.habr.com

Travis CI, Buddy eta AppVeyor-en konpromisoen eta tira-eskaeren azterketa PVS-Studio erabiliz