ProHoster >> Blog >> Administrimi >> Analiza e komiteteve dhe pull request përmes Travis CI, Buddy dhe AppVeyor duke përdorur PVS-Studio

Analiza e komiteteve dhe pull request përmes Travis CI, Buddy dhe AppVeyor duke përdorur PVS-Studio

Analiza e komitëve dhe pull request'ave 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, është shtuar një mundësi testuese për të kontrolluar listën e skedareve të përcaktuara. Me anë të këtij mënyre të re, mund të konfigurohet analizatori për të kontrolluar angazhimet dhe kërkesat e tërheqjes. Në këtë artikull do të diskutohet se si të konfigurohet kontrolli i listës së skedareve të ndryshuara në projektin GitHub në sisteme të njohura CI (Continuous Integration) si Travis CI, Buddy dhe AppVeyor.

Mënyra e kontrollit të listës së skedareve

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. Punon nĂ« sisteme 64-bit nĂ« Windows, Linux dhe macOS.

Në versionin PVS-Studio 7.04 për Linux dhe macOS u shtua mënyra e kontrollit të listës së skedareve burimore. Kjo funksionon për projektet, sistemi i ndërtimit i të cilave lejon gjenerimin e skedarit compile_commands.json. Nevojitet për të lejuar analizatorin të nxjerrë informacionin mbi kompilimin e skedareve të përcaktuara. Nëse sistemi juaj i ndërtimit nuk mbështet gjenerimin e skedarit compile_commands.json, mund të provoni ta gjeneroni këtë skedar me anë të utilitarit Bear.

Njëherazi, 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ë, ju do të duhet së pari të kryeni një ndërtim të plotë të projektit dhe ta gjurmoni atë, në mënyrë që analizatori të mbledhë informacione të plota mbi parametrat e kompilimit të të gjithë skedarëve të kontrolluar.

MegjithatĂ«, ky variant ka njĂ« disavantazh tĂ« rĂ«ndĂ«sishĂ«m — do tĂ« duhet ose tĂ« kryeni njĂ« gjurmim tĂ« plotĂ« tĂ« ndĂ«rtimit tĂ« gjithĂ« projektit nĂ« çdo fillim, qĂ« vetĂ« Ă«shtĂ« nĂ« kundĂ«rshtim me idenĂ« e kontrollit tĂ« shpejtĂ« tĂ« komedit. Ose, nĂ«se e ruani rezultatin e gjurmimit, ekzekutimet e ardhshme tĂ« analizatorit mund tĂ« jenĂ« tĂ« paplota, nĂ«se struktura e varĂ«sive tĂ« skedarĂ«ve burimor ndryshon pas gjurmimit (pĂ«r shembull, nĂ« njĂ« nga skedarĂ«t burimor do tĂ« shtohet njĂ« #include e re).

Prandaj, ne nuk rekomandojmë përdorimin e modës së kontrollit të listës së skedarëve me log të gjurmimit për kontrollin e komedive ose pull request-eve. Nëse mund të bëni një ndërtim inkremental gjatë kontrollit të komedit, shqyrtoni mundësinë e përdorimit të modës analizës inkrementale.

Lista e skedarëve burimorë për analizë ruhet në një skedë teksti dhe i dërgohet analizuesit me anë të parametrave. -S:

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

Në këtë skedë specifikohen rrugët e relative ose absolute të skedarëve, duke qenë që çdo skedë e re duhet të jetë në një rresht të ri. Lejohet të specifikoni jo vetëm emrat e skedarëve për analizë, por edhe tekst të ndryshëm. Analizuesi do të shohë që kjo nuk është një skedë dhe do ta injorojë rreshtin. Kjo mund të jetë e dobishme për komentim, nëse skedarët specifikohen manualisht. Megjithatë, shpesh lista e skedarëve do të gjenerohet gjatë analizës në CI, për shembull, këto mund të jenë skedarë nga komenti ose një pull request.

Tani, me kĂ«tĂ« modalitet, mund tĂ« kontrolloni shpejt kodin e ri para se ai tĂ« kalojĂ« nĂ« degĂ«n kryesore tĂ« zhvillimit. PĂ«r tĂ« bĂ«rĂ« qĂ« sistemi i kontrollit tĂ« reagojĂ« ndaj prani tĂ« paralajmĂ«rimeve nga analizuesi, nĂ« utilitarin plog-converter Ă«shtĂ« shtuar njĂ« flag —indicate-warnings:

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

Me këtë flamur, konvertuesi do të kthejë një kod të ndryshëm nëse raporti i analizatorit përmban paralajmërime. Sipas kodit të kthimit, mund të bllokoni hook-un para komisionit, komisionin ose pull request-in, dhe raportin e generuar nga analizatori ta shfaqni në ekran, ta ndani ose ta dërgoni me email.

Shënim. Në fillim të analizës, lista e skedarëve do të analizojë të gjithë projektin, pasi analizatori duhet të generejë skedarin e varësive të skedarëve burimorë nga skedarët përkatës. Kjo është një veçori e analizës së skedarëve C dhe C++. Më pas, skedari i varësive mund të ruhet në cache dhe do të përditësohet automatikisht nga analizatori. Avantazhi i kontrollit të komisioneve kur përdorni modin e kontrollit të listës së skedarëve përpara se të përdorni modin e analizës inkrementale është që është mjaft të ruani vetëm këtë skedar, dhe jo skedarët objekt.

Principet e zakonshme të analizës së pull request-it

Analiza e të gjithë projektit merr mjaft kohë, prandaj ka kuptim të kontrolloni vetëm një pjesë të tij. Problemi është se duhet të ndahen skedarët e rinj nga skedarët e tjerë të projektit.

Le të shqyrtojmë një shembull të një tree commit-i me dy degë:

Analiza e komitëve dhe pull request'ave në Travis CI, Buddy dhe AppVeyor me PVS-Studio

Le të imagjinojmë se commit-i A1 përmban një sasi të mjaftueshme kodi, që është kontrolluar tashmë. Pak më parë kemi bërë një degë nga commit-i A1 dhe kemi ndryshuar disa skedarë.

Sigurisht, keni vënë re se pas A1 ndodhi edhe dy commit-e të tjera, por gjithashtu ishin bashkime të degëve të tjera, pasi ne nuk po commit-i në master. Dhe ka ardhur koha kur hotfix është gati. Prandaj, u paraqit një pull request për bashkim B3 dhe A3.

Natyrisht, do të ishte e mundur të kontrollohej e gjithë rezultati i bashkimit të tyre, por do të ishte shumë e gjatë dhe e pasigurt, pasi janë ndryshuar vetëm disa skedarë. Prandaj, është më efektive të analizohet vetëm ato të ndryshuara.

Për këtë, do të marim dallimin midis degëve, duke qenë në HEAD të degës, nga e cila duam të derdhim në master:

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

$MERGE_BASE do ta shqyrtojmĂ« me detaje mĂ« vonĂ«. Çështja Ă«shtĂ« se jo çdo shĂ«rbim CI ofron informacionin e nevojshĂ«m pĂ«r bazĂ«n e bashkimit, prandaj çdo herĂ« duhet tĂ« shpikim mĂ«nyra tĂ« reja pĂ«r tĂ« marrĂ« kĂ«to tĂ« dhĂ«na. Kjo do tĂ« pĂ«rshkruhet nĂ« detaje mĂ« poshtĂ« nĂ« çdo njĂ« nga shĂ«rbimet e pĂ«rshkruara.

KĂ«shtu, ne morĂ«m ndryshimin midis degĂ«ve, pĂ«rkatĂ«sisht — listĂ«n e emrave tĂ« skedarĂ«ve qĂ« janĂ« ndryshuar. Tani na nevojitet tĂ« dĂ«rgojmĂ« skedarin .pvs-pr.list (ne e ridrejtuam daljen mĂ« sipĂ«r) analizatorit:

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

Pas analizës na duhet të konvertojmë skedarin e logjeve (PVS-Studio.log) në një format më të lexueshëm:

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

Kjo komandë do të nxjerrë një listë gabimesh në stderr (rrjedha standarde e mesazheve të gabimeve).

Por na nevojitet jo vetĂ«m tĂ« nxjerrim gabimet, por edhe tĂ« njoftojmĂ« shĂ«rbimin tonĂ« pĂ«r ndĂ«rtimin dhe testimin pĂ«r praninĂ« e problemeve. PĂ«r kĂ«tĂ«, nĂ« konvertues Ă«shtĂ« shtuar njĂ« flag -W (—indicate-warnings). NĂ«se ka edhe njĂ« paralajmĂ«rim tĂ« analizatorit, kodi i kthimit tĂ« utilitarit plog-converter do tĂ« ndryshojĂ« nĂ« 2, qĂ«, nga ana e tij, do t'i njoftojĂ« shĂ«rbimit CI pĂ«r praninĂ« e gabimeve tĂ« mundshme nĂ« skedarin e pull request.

Travis CI

Konfigurimi është realizuar në formën e skedarit .travis.yml. Për komfort, rekomandoj të nxirreni gjithçka në një skript bash të veçantë me funksione, të cilat do të thirren nga skedari .travis.yml (bash emri_i_skriptit.sh emri_i_funksionit).

Do të fillojmë të shtojmë kodin e nevojshëm në skript në bash, kështu do të kemi funksionalitet më të madh. Në seksionin install do të shkruajmë këtë:

instaloni:
  - bash .travis.sh travis_install

Nëse keni ndonjë udhëzim, mund ta transferoni atë në skenarin duke hequr pikësi.

Do të hapim skedarin .travis.sh dhe do të shtojmë instalimin e analizuesit 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 do të shtojmë në seksionin script ekzekutimi i analizës:

skenari:
  - 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 kod duhet të ekzekutohet pas ndërtimit të projektit, për shembull, nëse keni pasur një ndërtim në CMake:

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

Do të dalë 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 keni vërejtur tashmë variablat e përmendur të ambientit $TRAVIS_PULL_REQUEST dhe $TRAVIS_BRANCH. Travis CI i shpall ato vetë:

  • $TRAVIS_PULL_REQUEST mban numrin e kĂ«rkesĂ«s pĂ«r ndihmĂ« ose false, nĂ«se Ă«shtĂ« njĂ« degĂ« e zakonshme;
  • $TRAVIS_REPO_SLUG mban emrin e repozitorit tĂ« projektit.

Algoritmi i funksionit është:

Analiza e komitëve dhe pull request'ave në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Travis CI reagon ndaj kodit të kthimit, prandaj prania e paralajmërimeve do t'i tregon shërbimit se komiti ka përmbajtje gabimesh.

Tani le të shqyrtojmë më në detaje këtë rresht të kodit:

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

Fakti është se Travis CI automatikisht bëjnë bashkimin e degëve gjatë analizës së kërkesës për ndihmë:

Analiza e komitëve dhe pull request'ave në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Prandaj, ne analizojmë A4, jo B3->A3. Për këtë arsye, na nevojitet të llogarisim ndryshimin me A3, që është pikërisht maja e degës nga origin.

Ka mbetur njĂ« detaj i rĂ«ndĂ«sishĂ«m — keĆĄimi i varĂ«sive tĂ« skedarĂ«ve tĂ« titujve nga njĂ«sitĂ« e pĂ«rkthimit (*.c, *.cc, *.cpp etj.). KĂ«to varĂ«si analizi kalkulohet gjatĂ« fillimit tĂ« parĂ« nĂ« modalitetin e kontrollit tĂ« listĂ«s sĂ« skedarĂ«ve dhe mĂ« pas ruhet nĂ« drejtorinĂ« .PVS-Studio. Travis CI lejon keĆĄimin e dosjeve, kĂ«shtu qĂ« ne do ta ruajmĂ« tĂ« dhĂ«nat e kĂ«saj drejtorie. .PVS-Studio/:

cache:
  directories:
    - .PVS-Studio/

Ky kod duhet të shtohet në skedarin .travis.yml. Kjo drejtorie ruan të dhëna të ndryshme të mbledhura pas analizës, të cilat do të përshpejtojnë shpejt analizat e mëvonshme të listës së skedarëve ose analizat inkrementale. Nëse nuk e bëni këtë, analisti do të analizojë faktikisht çdo herë të gjitha skedarët.

Buddy

Si Travis CI, Buddy ofron mundësinë e ndërtimit automatizuar dhe testimit të projekteve që ruhen në GitHub. Ndryshe nga Travis CI, ai konfiguriket në ndërfaqen e uebit (ka mbështetje për bash), kështu që nuk ka nevojë të ruani skedarët e konfigurimit në projekt.

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

Analiza e komitëve dhe pull request'ave në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Do të tregojmë kompiluesin 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 ekziston një kontejner i veçantë:

Analiza e komitëve dhe pull request'ave në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Tani do të instalojmë PVS-Studio dhe utilitetet e nevojshme:

Analiza e komitëve dhe pull request'ave 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 kalojmë në tabin Run (ikona e parë) dhe në fushën përkatëse të redaktorit shtoni kodin e mëposhtëm:

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 kapitullin që i kushtohet Travs-CI, ky kod tashmë ju është i njohur, megjithatë, tani ka një fazë të re:

Analiza e komitëve dhe pull request'ave në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Tani ne po analizojmë jo rezultatin e bashkimit, por HEAD të degës nga e cila bëhet kërkesa për të tërhequr:

Analiza e komitëve dhe pull request'ave në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Prandaj, jemi në një komit të kushtëzuar B3 dhe na nevojitet të marrim ndryshimin me 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, të cilat i ofron Buddy:

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

Tani, do të ruajmë ndryshimet duke përdorur butonin poshtë dhe do të aktivizojmë analizën e kërkesës për të tërhequr:

Analiza e komitëve dhe pull request'ave në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Ndryshe nga Travis CI, nuk kemi nevojĂ« tĂ« specifikojmĂ« .pvs-studio pĂ«r caching, pasi Buddy automatikisht ruan tĂ« gjitha skedarĂ«t pĂ«r ekzekutime tĂ« mĂ«vonshme. Prandaj, mbetet e fundit — ruajmĂ« emrin e pĂ«rdoruesit dhe fjalĂ«kalimin pĂ«r PVS-Studio nĂ« Buddy. Pas ruajtjes sĂ« ndryshimeve, ne do tĂ« kthehemi tek Pipeline. Na nevojitet tĂ« kalojmĂ« te konfigurimi i variablave dhe tĂ« shtojmĂ« emrin e pĂ«rdoruesit dhe çelĂ«sin pĂ«r PVS-Studio:

Analiza e komitëve dhe pull request'ave 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Ă« nisĂ« verifikimin. NĂ«se komiti pĂ«rmban gabime, Buddy do ta tregojĂ« kĂ«tĂ« nĂ« faqen e pull request‘it.

AppVeyor

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

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

Analiza e komitëve dhe pull request'ave në Travis CI, Buddy dhe AppVeyor me PVS-Studio
TĂ« rrokullisim kĂ«tĂ« faqe poshtĂ« dhe tĂ« aktivizojmĂ« ruajtjen e caches pĂ«r ndĂ«rtimet e pull request‘eve:

Analiza e komitëve dhe pull request'ave në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Tani kalojmë në skedën Environment, ku do të japim imazhin për ndërtimin dhe variablat e nevojshme të mjedisit:

Analiza e komitëve dhe pull request'ave në Travis CI, Buddy dhe AppVeyor me PVS-Studio
NĂ«se e ke lexuar seksionet e mĂ«parshme, ti je i njohur mirĂ« me kĂ«to dy variabla — PVS_KEY dhe PVS_USERNAME. NĂ«se jo, tĂ« kujtoj se ato janĂ« tĂ« nevojshme pĂ«r verifikimin e licencĂ«s sĂ« analizuesit PVS-Studio. MĂ« vonĂ« do t'i hasim pĂ«rsĂ«ri nĂ« skriptet Bash.

Në këtë faqe poshtë do të japim dosjen për cache:

Analiza e komitëve dhe pull request'ave në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Nëse nuk e bëjmë këtë, do të analizojmë të gjithë projektin në vend të disa skedarëve, por do të marrim rezultatin për skedarët e dhënë. Prandaj, është e rëndësishme të jepni emrin e duhur të drejtorisë.

Tani ka ardhur koha për skriptin e verifikimit. Do të hapim skedën Tests dhe do të zgjedhim Script:

Analiza e komitëve dhe pull request'ave në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Në këtë formë duhet të ngjisni kodin e 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

Të vëmë re pjesën e mëposhtme 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

Përcaktimi i mjaftueshëm i vlerës së komandës pwd në një variabël që duhet të ruajë këtë vlerë si të parazgjedhur duket e çuditshme në shikim të parë, megjithatë, tani do ta shpjegoj gjithçka.

Gjatë konfigurimit të analizuesit në AppVeyor, u përballa me një sjellje mjaft të çuditshme të analizuesit. Nga njëra anë, çdo gjë funksiononte siç duhet, por analiza nuk fillonte. Kam kaluar një kohë të gjatë për të vënë re se ndodheshim në direktorinë /home/appveyor/projects/testcalc/, ndërsa analizuesi ishte i sigurt se ndodheshim në /opt/appveyor/build-agent/. Kështu kuptova se variabla $PWD po tregon disa të pavërteta. Për këtë arsye, e përditësova manualisht vlerën e saj para fillimit të analizës.

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

Analiza e komitëve dhe pull request'ave në Travis CI, Buddy dhe AppVeyor me PVS-Studio
Tani le të shqyrtojmë fragmentin e ardhshë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ë, marrim ndryshimin midis degëve mbi të cilat është shpallur pull request. Për këtë na nevojiten këto variabla ambienti:

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

PĂ«rfundimi

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

Diku, si në Travis-CI, disa rreshta kodi dhe caching funksionon përsosur; diku tjetër, si në AppVeyor, thjesht duhet të specifikoni dosjen në konfigurime; por diku tjetër duhet të krijoni çelësa unikë dhe të përpiqeni të bindni sistemin për t'ju lejuar të rinovoni fragmentin e caktuar. Prandaj, nëse dëshironi të konfiguroni analizën e pull request'ave në një shërbim të integrimit të vazhdueshëm që nuk është shqyrtuar më sipër, sigurohuni që nuk do të keni probleme me caching.

Faleminderit për vëmendjen. Nëse diçka nuk shkon ashtu siç duhet, mos hezitoni të na shkruani në mbështetje. Ne do t'ju ndihmojmë dhe udhëzojmë.

Analiza e komitëve dhe pull request'ave në Travis CI, Buddy dhe AppVeyor me PVS-Studio

Nëse dëshironi të ndani këtë artikull me audiencën anglisht-folëse, ju lutem përdorni lidhjen për përkthimin: Maxim Zvyagintsev. Analiza e komitëve dhe pull request'ave në Travis CI, Buddy dhe AppVeyor duke përdorur PVS-Studio.

Burimi: habr.com

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster