ProHoster > Blog > Administrim > Analiza e komiteteve dhe pull request-eve në Travis CI, Buddy dhe AppVeyor me PVS-Studio

Analiza e komiteteve dhe pull request-eve në Travis CI, Buddy dhe AppVeyor me PVS-Studio

Analiza e komiteve dhe kërkesave për tërheqje në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Në analizatorin PVS-Studio për gjuhët C dhe C++ në Linux dhe macOS, duke filluar nga versioni 7.04, ka një mundësi testimi për të kontrolluar listën e skedarëve të caktuar. Me ndihmën e modit të ri, mund të konfiguroni analizatorin për të verifikuar commit-et dhe pull request-et. Në këtë artikull do të flitet se si të konfiguroni verifikimin e listës së skedarëve të ndryshuar në projektin GitHub në disa nga sistemet e njohura CI (Continuous Integration), si Travis CI, Buddy dhe AppVeyor.

Mjeti për kontrollin e listës së skedarëve

PVS-Studio — Ă«shtĂ« njĂ« mjet pĂ«r identifikimin e gabimeve dhe dobĂ«sive tĂ« mundshme nĂ« kodin burimor tĂ« programeve tĂ« shkruara nĂ« gjuhĂ«t C, C++, C# dhe Java. Funksionon nĂ« sisteme 64-bit nĂ« Windows, Linux dhe macOS.

Në versionin PVS-Studio 7.04 për Linux dhe macOS u prezantua moda e kontrollit të listës së skedarëve burimor. Kjo funksionon për projektet, sistemi i ndërtimit të cilave lejon gjenerimin e skedarit compile_commands.json. Ai është i nevojshëm që analizatori të nxjerrë informacion mbi kompilimin e skedarëve të caktuar. Nëse sistemi juaj i ndërtimit nuk mbështet gjenerimin e skedarit compile_commands.json, mund të provoni ta gjeneroni një skedar të tillë me ndihmën e utilitarit Bear.

Gjithashtu, moda e kontrollit të listës së skedarëve mund të përdoret së bashku me logun e gjurmimit strace të kompilimeve (pvs-studio-analyzer trace). Për këtë, do t'ju nevojitet të bëni një ndërtim të plotë të projektit dhe ta gjurmoni atë, në mënyrë që analizatori të mbledhë informacionin e plotë mbi parametrat e kompilimit të të gjithë skedarëve të kontrolluar.

MegjithatĂ«, ky variant ka njĂ« disavantazh tĂ« dukshĂ«m—duhet tĂ« kryeni njĂ« gjurmim tĂ« plotĂ« tĂ« ndĂ«rtimit tĂ« gjithĂ« projektit nĂ« çdo ekzekutim, e cila vetĂ« bie ndesh me idenĂ« e kontrollit tĂ« shpejtĂ« tĂ« commit-it. Ose, nĂ«se e konservoni rezultatin e gjurmimit, ekzekutimet e mĂ«vonshme tĂ« analizatorit mund tĂ« rezultojnĂ« tĂ« paplota, nĂ«se pas gjurmimit struktura e varĂ«sive tĂ« skedarĂ«ve burimor ndryshon (pĂ«r shembull, nĂ« njĂ« nga skedarĂ«t burimor do tĂ« shtohet njĂ« #include e re).

Prandaj, ne nuk e rekomandojmë përdorimin e modës së kontrollit të listës së skedarëve me logun e gjurmimit për kontrollin e commit-eve ose pull request-eve. Nëse keni mundësi të bëni një ndërtim inkremental gjatë kontrollit të commit-it, konsideroni të përdorni modën e analizës inkrementale.

Lista e skedarëve burimor për analizë ruhet në një skedar tekstual dhe i dorëzohet analizatorit me anë të parametrave -S:

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

NĂ« kĂ«tĂ« skedar, pĂ«rcaktohen rrugĂ«t_relative ose_absolute pĂ«r skedarĂ«t, duke filluar njĂ« skedar tĂ« ri nĂ« çdo vijĂ« tĂ« re. ËshtĂ« e lejueshme tĂ« specifikoni jo vetĂ«m emrat e skedarĂ«ve pĂ«r analizĂ«, por edhe tekst tĂ« ndryshĂ«m. Analizuesi do tĂ« kuptojĂ« qĂ« kjo nuk Ă«shtĂ« njĂ« skedar dhe do ta injorojĂ« atĂ«. Kjo mund tĂ« jetĂ« e dobishme pĂ«r komente, nĂ«se skedarĂ«t specifikohen manualisht. MegjithatĂ«, shpeshherĂ« lista e skedarĂ«ve do tĂ« gjenerohet gjatĂ« analizĂ«s nĂ« CI, pĂ«r shembull, kĂ«to mund tĂ« jenĂ« skedarĂ« nga komiti ose pull request.

Tani, me këtë mod, është e mundur të kontrolloni shpejt kodin e ri para se të arrijë në degën kryesore të zhvillimit. Për të bërë që sistemi i kontrollit të reagojë ndaj paralajmërimeve të analizuesit, në utilitarin plog-converter është shtuar një flag --indicate-warnings:

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

Me këtë flag, konvertori do të kthejë një kod jo-zero nëse raporti i analizuesit përmban paralajmërime. Nëpërmjet kodit të kthimit, mund të bllokoni hook-un e para-commit, commit-in ose pull request-in, dhe raportin e gjeneruar të analizuesit ta shfaqni në ekran, ta ndani ose ta dërgoni me postë.

ShĂ«nim. NĂ« fillimin e parĂ« tĂ« analizĂ«s sĂ« listĂ«s sĂ« skedarĂ«ve, do tĂ« analizohet e gjithĂ« projekti, pasi analizuesi ka nevojĂ« tĂ« gjenerojĂ« njĂ« skedar varĂ«sish pĂ«r skedarĂ«t burimorĂ« tĂ« projektit nga skedarĂ«t e titujve. Kjo Ă«shtĂ« njĂ« veçori e analizĂ«s sĂ« skedarĂ«ve C dhe C++. MĂ« pas, skedari i varĂ«sive mund tĂ« ĐșДшohet dhe do tĂ« pĂ«rditĂ«sohet automatikisht nga analizuesi. Avantazhi i kontrollit tĂ« komiteteve gjatĂ« pĂ«rdorimit tĂ« modit tĂ« kontrollit tĂ« listĂ«s sĂ« skedarĂ«ve, nĂ« krahasim me pĂ«rdorimin e modit tĂ« analizĂ«s inkrementale, Ă«shtĂ« se duhet tĂ« ĐșДшoni vetĂ«m kĂ«tĂ« skedar dhe jo skedarĂ«t objekt.

Principet e përgjithshme të analizës së pull request-it

Analiza e të gjithë projektit merr shumë kohë, kështu që ka kuptim të kontrolloni vetëm një pjesë të tij. Problemi është se duhet të dalloni skedarët e rinj nga skedarët e tjerë të projektit.

Le të marrim një shembull të pemës së komiteteve me dy dega:

Analiza e komiteve dhe kërkesave për tërheqje në Travis CI, Buddy dhe AppVeyor me PVS-Studio

Le të imagjinojmë se komiti A1 përmban një sasi të madhe të kodit që është kontrolluar tashmë. Pak më parë kemi bërë një degë nga komiti A1 dhe kemi ndryshuar disa skedarë.

Natyrisht, keni vĂ«nĂ« re se pas A1 ka pasur edhe dy komitete tĂ« tjera, por ato janĂ« gjithashtu bashkime tĂ« degĂ«ve tĂ« tjera, pasi ne nuk bĂ«jmĂ« commit nĂ« master. Dhe ka ardhur koha kur hotfix ĐłĐŸŃ‚ĐŸĐČ. Kjo Ă«shtĂ« arsyeja pse Ă«shtĂ« krijuar njĂ« pull request pĂ«r bashkimin B3 dhe A3.

Natyrisht, mund të kontrollohej rezultati i plotë i bashkimit, por do të ishte shumë e gjatë dhe e pamundshme, pasi janë ndryshuar vetëm disa skedarë. Prandaj është më efikase të analizohet vetëm ajo që është ndryshuar.

Për këtë, do të marrim diferencën midis degëve, duke qëndruar në HEAD të degës nga e cila duam të bashkojmë në master:

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

$MERGE_BASE ne do të shqyrtojmë në detaje më vonë. Problemi është se jo çdo shërbim CI ofron informacionin e nevojshëm rreth bazës për bashkimin, prandaj çdo herë duhet të shpikim mënyra të reja për të marrë këto të dhëna. Kjo do të shihet më në detaje më poshtë në çdo nga shërbimet e përmendura të uebit.

KĂ«shtu, morĂ«m diferencĂ«n midis degĂ«ve, mĂ« saktĂ«sisht — listĂ«n e emrave tĂ« skedarĂ«ve qĂ« janĂ« ndryshuar. Tani na nevojitet tĂ« dĂ«rgojmĂ« skedarin .pvs-pr.list (ne e kemi ridrejtur daljen mĂ« lart) analizatorit:

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

Pas analizës, na nevojitet të konvertojmë skedarin e logjeve (PVS-Studio.log) në një format më të lehtë për t'u kuptuar:

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

Ky komandë do të nxjerrë një listë gabimesh në stderr (në rrjedhën standarde të output-it të mesazheve të gabimeve).

Por ne na nevojitet të nxjerrim jo vetëm gabimet, por edhe ta njoftojmë shërbimin tonë për ndërtim dhe testim për praninë e problemeve. Për këtë, në konvertues është shtuar një flamur -W (--indicate-warnings). Me praninë e edhe një paralajmërimi nga analizatori, kodi e kthyer nga utiliteti plog-converter do të ndryshojë në 2, që, nga ana e tij, do t'i raportojë shërbimit CI për praninë e gabimeve potenciale në skedarët e pull request-it.

Travis CI

Konfigurimi është bërë në formën e një skedari .travis.yml. Për lehtësinë tuaj, sugjeroj të nxjerrim gjithçka në një skenar të veçantë bash me funksione, të cilat do të thirren nga skedari .travis.yml (bash emri_skriptit.sh emri_funksionit).

Do ta shtojmë kodin e nevojshëm në skenar në bash, kështu që do të kemi më shumë funksionalitet. Në seksionin instalo do të shkruajmë si më poshtë:

install:
  - bash .travis.sh travis_install

Nëse keni pasur ndonjë udhëzimi, mund t'i transferoni ato në skenar, duke hequr simbolin -.

Do të hapim skedarin .travis.sh dhe do të shtojmë instalimin e analizatorit në funksionin 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 
}

Tani shtojmë në seksionin script nisja e analizës:

script:
  - bash .travis.sh travis_script

Dhe në skenarin bash:

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
}

Ky kyç duhet të ekzekutohet pas ndërtimit të projektit, për shembull, nëse keni pasur ndërtim me CMake:

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

Do të rezultojë kështu:

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
}

Ndoshta e keni vënë re tashmë variablat e mjedisit të përmendura. $TRAVIS_PULL_REQUEST dhe $TRAVIS_BRANCH. Travis CI i shpall këto automatikisht:

  • $TRAVIS_PULL_REQUEST ruan numrin e kĂ«rkesĂ«s pĂ«r bashkim ose false, nĂ«se Ă«shtĂ« njĂ« degĂ« e zakonshme;
  • $TRAVIS_REPO_SLUG ruan emrin e depozitĂ«s sĂ« projektit.

Algoritmi i funksionit është:

Analiza e komiteve dhe kërkesave për tërheqje në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Travis CI reagon ndaj kodit të kthyeseve, kështu që pranimi i paralajmërimeve do t'i tregojë shërbimit të markojë komitin si që përmban gabime.

Tani le të shikojmë më në hollësi këtë rresht të kodit:

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

Çështja Ă«shtĂ« se Travis CI automatikisht bĂ«n bashkimin e degĂ«ve gjatĂ« analizĂ«s sĂ« kĂ«rkesĂ«s pĂ«r bashkim:

Analiza e komiteve dhe kërkesave për tërheqje në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Prandaj ne analizojmë A4, e jo B3->A3. Për shkak të kësaj veçorie, na nevojitet të llogarisim ndryshimin me A3, e cila është pikërisht maja e degës nga origin.

Ka njĂ« detaj tĂ« rĂ«ndĂ«sishĂ«m tĂ« mbetur — ruajtja e varĂ«sive tĂ« skedarĂ«ve tĂ« titujve nga njĂ«sitĂ« e pĂ«rkthimit tĂ« kompiluar (*.c, *.cc, *.cpp, etj.). KĂ«to varĂ«si analizatori i llogarit gjatĂ« startit tĂ« parĂ« nĂ« modusin e kontrollit tĂ« listĂ«s sĂ« skedarĂ«ve dhe mĂ« pas i ruan nĂ« drejtorinĂ« .PVS-Studio. Travis CI lejon ruajtjen e dosjeve, prandaj ne do tĂ« ruajmĂ« tĂ« dhĂ«nat e drejtorisĂ« .PVS-Studio/:

cache:
  directories:
    - .PVS-Studio/

Ky kod duhet të shtohet në skedarin .travis.ymlKjo direktorë mban të dhëna të ndryshme të mbledhura pas analizës, të cilat do të përshpejtojnë ndjeshëm lancimet e ardhshme të analizës së listës së skedarëve ose analizës inkramentale. Nëse nuk e bëni këtë, analisti faktikisht do të analizohet çdo herë të gjitha skedarët.

Buddy

Ashtu si Travis CI, Buddy ofron mundësinë për ndërtim dhe testim automatizues të projekteve që ruhen në GitHub. Ndryshe nga Travis CI, ai konfigurohet në ndërfaqen web (ka mbështetje për bash), prandaj nuk ka nevojë të ruani skedarët e konfigurimit në projekt.

Së pari, na nevojitet të shtojmë një veprim të ri në linjën e ndërtimit:

Analiza e komiteve dhe kërkesave për tërheqje në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Të përcaktojmë kompjuterin që u përdor për ndërtimin e projektit. Vini re kontejnerin docker që është instaluar në këtë veprim. Për shembull, për GCC ka një kontejner të veçantë:

Analiza e komiteve dhe kërkesave për tërheqje në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Tani do të instalojmë PVS-Studio dhe utilitetet e nevojshme:

Analiza e komiteve dhe kërkesave për tërheqje në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Shtoni në redaktor këto rreshta:

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

Tani, le të kalojmë në tab-in Run (ikona e parë) dhe në fushën përkatëse të redaktorit të shtojmë këtë kod:

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

Nëse keni lexuar pjesën mbi Travs-CI, ky kod tashmë ju është i njohur, megjithatë tani ka një fazë të re:

Analiza e komiteve dhe kërkesave për tërheqje në Travis CI, Buddy dhe AppVeyor me PVS-Studio
E mira është se tani po analizojmë jo rezultatin e bashkimit, por HEAD të degës nga e cila bëhet kërkesa për tërheqje:

Analiza e komiteve dhe kërkesave për tërheqje në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Prandaj ndodhemi në një komit të supozuar B3 dhe na nevojitet të marrim diferencën nga 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

Për të përcaktuar A3 do të përdorim API-në e GitHub:

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

Ne kemi përdorur këto variabla që ofron Buddy:

  • $BUDDY_EXECUTION_PULL_REQEUST_NO — numri i kĂ«rkesĂ«s pĂ«r tĂ«rheqje;
  • $BUDDY_REPO_SLUG — kombinimi i emrit tĂ« pĂ«rdoruesit dhe depozitĂ«s (pĂ«r shembull max/test).

Tani do tadhe ndryshimet, duke e shfrytzuar butonin poshtë, dhe do ta aktivizojmë analizën e pull request:

Analiza e komiteve dhe kërkesave për tërheqje në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Ndryshe nga Travis CI, nuk kemi nevojĂ« tĂ« specifikojmĂ« .pvs-studio pĂ«r cache, pasi qĂ« Buddy automatikisht ruan tĂ« gjitha skedarĂ«t pĂ«r ekzekutimet e ardhshme. Prandaj na mbetet e fundit — tĂ« ruajmĂ« emrin e pĂ«rdoruesit dhe fjalĂ«kalimin pĂ«r PVS-Studio nĂ« Buddy. Pas ruajtjes sĂ« ndryshimeve, do tĂ« kthehemi pĂ«rsĂ«ri nĂ« Pipeline. Na duhet tĂ« kalojmĂ« nĂ« vendosjen e variablave dhe tĂ« shtojmĂ« emrin e pĂ«rdoruesit dhe çelĂ«sin pĂ«r PVS-Studio:

Analiza e komiteve dhe kërkesave për tërheqje në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Pas kësaj, shfaqja e një pull request-i të ri ose e një komiti do të aktivizojë verifikimin. Nëse komiti përmban gabime, atëherë Buddy do ta shfaqë atë në faqen e pull request-it.

AppVeyor

Konfigurimi i AppVeyor është i ngjashëm me atë të Buddy, pasi gjithçka ndodh në ndërfaqen web dhe nuk ka nevojë të shtojmë skedarin *.yml në repositorin e projektit.

Të kalojmë në tabin Settings në përmbledhjen e projektit:

Analiza e komiteve dhe kërkesave për tërheqje në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Të rrotullojmë këtë faqe poshtë dhe të aktivizojmë ruajtjen e cache-it për ndërtimet e pull request-ve:

Analiza e komiteve dhe kërkesave për tërheqje në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Tani të kalojmë në tabin Environment, ku do të specifikojmë imazhin për ndërtim dhe variablat e nevojshme të ambientit:

Analiza e komiteve dhe kërkesave për tërheqje në Travis CI, Buddy dhe AppVeyor me PVS-Studio
NĂ«se i keni lexuar seksionet e mĂ«parshme, jeni tĂ« njohur me kĂ«to dy variabla — PVS_KEY dhe PVS_USERNAME. NĂ«se jo, atĂ«herĂ« po ju kujtoj se janĂ« tĂ« nevojshme pĂ«r verifikimin e licencĂ«s sĂ« analizuesit PVS-Studio. MĂ« vonĂ« do t'i takojmĂ« sĂ«rish nĂ« skriptet Bash.

Në këtë faqe po ashtu, poshtë, do të specifikojmë dosjen për ruajtje në cache:

Analiza e komiteve dhe kërkesave për tërheqje në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Nëse nuk e bëjmë këtë, do të analizohet e gjithë projekti në vend të disa skedarëve, por do ta marrim daljen sipas skedarëve të specifikuar. Prandaj është e rëndësishme të futet emri i saktë i direktorisë.

Tani ka ardhur koha për skriptin për verifikim. Të hapim tabin Tests dhe të zgjedhim Script:

Analiza e komiteve dhe kërkesave për tërheqje në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Në këtë formë duhet të futet kodi i mëposhtëm:

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

Le të kuptojmë pjesën tjetër të kodit:

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

Duket se është një caktim specifik i vlerës së komandës pwd në një variabël që duhet të ruajë këtë vlerë si standart, duket e çuditshme në shikim të parë, por tani do ta shpjegoj.

Gjatë konfigurimit të analizuesit në AppVeyor, u ndesha me një sjellje mjaft çuditshme të analizuesit. Nga njëra anë, gjithçka funksiononte siç duhet, por analiza nuk fillonte. Shpenzova shumë kohë për të vënë re se ishim në direktoriumin /home/appveyor/projects/testcalc/, ndërsa analizuesi ishte i bindur se ndodheshim në /opt/appveyor/build-agent/. Atëherë kuptova se variabla $PWD po gënjen pak. Për këtë arsye, e azhurnova manualisht vlerën e saj para fillimit të analizës.

Dhe pastaj gjithçka është si më parë:

Analiza e komiteve dhe kërkesave për tërheqje në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Tani le të shqyrtojmë fragmentin e mëposhtëm:

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

Në të ne marrim diferencën mes degëve për të cilat është shpallur pull request. Për këtë na duhen variablat e mëposhtëm të ambientit:

  • $APPVEYOR_PULL_REQUEST_NUMBER — numri i pull request;
  • $APPVEYOR_REPO_NAME — emri i pĂ«rdoruesit dhe repository e projektit.

PĂ«rfundim

Sigurisht, nuk shqyrtuam të gjitha shërbimet e mundshme të integrimit të vazhdueshëm, por të gjithë ato kanë një specifikë shumë të ngjashme me njëra-tjetrën. Me përjashtim të caching, çdo shërbim krijon "bicikletën" e tij, prandaj gjithmonë është ndryshe.

Dikund, si në Travis-CI, disa rreshta kodi dhe caching funksionon pa ecur; dikund, si në AppVeyor, thjesht duhet të tregosh dosjen në cilësimet; por ndokund nevojitet krijimi i çelësave unikë dhe përpjekja për të bindur sistemin që të të lejojë të ridhish një pjesë të ruajtur. Prandaj, nëse dëshiron të konfiguroni analizën e pull request-eve në një shërbim të integrimit të vazhdueshëm që nuk është shqyrtuar më lart, sigurohu së pari që caching nuk do të të shkaktojë probleme.

Faleminderit për vëmendjen. Nëse diçka nuk funksionon, mos hezitoni të na shkruani në mbështetje. Ne do t'ju ndihmojmë dhe do t'ju japim këshilla.

Analiza e komiteve dhe kërkesave për tërheqje në Travis CI, Buddy dhe AppVeyor me PVS-Studio

Nëse dëshironi ta ndani këtë artikull me një audiencë anglishtfolëse, ju lutem përdorni linkun për përkthimin: Maxim Zvyagintsev. Analiza e komiteve dhe kërkesave për tërheqje në Travis CI, Buddy dhe AppVeyor duke përdorur PVS-Studio.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster