ProHoster > Blog > Administrim > Analiza e merge request'ave në GitLab me PVS-Studio për C#

Analiza e merge request'ave në GitLab me PVS-Studio për C#

Analiza e kërkesave për bashkim në GitLab me PVS-Studio për C#
E dashuruar GitLab dhe nuk e doni gabimet? Dëshironi të rrisni cilësinë e kodit burimor? Atëherë, jeni në vendin e duhur. Sot do t'ju tregojmë se si të konfiguroni analizuesin C# PVS-Studio për të kontrolluar kërkesat e bashkimit. Të gjithë të kenë humor të bukur dhe lexim të këndshëm.

PVS-Studio është një mjet për identifikimin e gabimeve dhe vulnerabiliteteve potenciale 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. Mund të analizojë kodin e destinuar për platformat 32-bit, 64-bit dhe ARM të integruar.

Të gjitha, kemi lansuar PVS-Studio 7.08, në të cilin kemi bërë shumë gjëra interesante. Për shembull:

  • analizuesin C# pĂ«r Linux dhe macOS;
  • plugin pĂ«r Rider;
  • njĂ« mod pĂ«r kontrollin e listĂ«s sĂ« skedarĂ«ve.

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

Më parë, për të kontrolluar skedarët e caktuar, duhej t'i dergoheshit analizuesit një .xml me listën e skedarëve. Por pasi kjo nuk ishte shumë e përshtatshme, ne shtuam mundësinë e dërgimit të një .txt, e cila e thjeshton shumë jetën.

Për të kontrolluar skedarët e caktuar, është e nevojshme të tregoni flamur --sourceFiles (--follow) dhe të dërgoni një .txt me listën e skedarëve. Kjo duket kështu:

pvs-studio-dotnet -t path/to/solution.sln -f fileList.txt -o project.json

Nëse jeni të interesuar të konfiguroni kontrollin e komitëve ose kërkesave të bashkimit, gjithashtu mund ta bëni këtë duke përdorur këtë mod. Dallimi do të bëhet për marrjen e listës së skedarëve për analizë dhe do të varet nga cilat sisteme po përdorni.

Principi i kontrollit të kërkesave të bashkimit

Thelbi i kontrollit qëndron në atë që problemet e gjetura nga analizuesi të mos kalojnë në master degën. Gjithashtu, nuk dëshirojmë të analizojmë për Projektin çdo herë. Sidomos që në bashkim të degëve kemi një listë të skedarëve të ndryshuar. Prandaj, propozoj të shtojmë kontrollin e kërkesave të bashkimit.

Ja si duket kërkesa e bashkimit para se të vendoset analizuesi statik:

Analiza e kërkesave për bashkim në GitLab me PVS-Studio për C#
Pra, të gjitha gabimet që ishin në degën ndryshimet, do të kalonin në degën master. Të cilat nuk do të donim, shtojmë analizën, dhe tani skema duket kështu:

Analiza e kërkesave për bashkim në GitLab me PVS-Studio për C#
Analizojmë changes2 dhe, nëse nuk ka gabime, pranojmë kërkesën e bashkimit, përndryshe e refuzojmë.

Të gjitha, nëse jeni të interesuar për analizën e komitëve dhe kërkesave të bashkimit për C/C++, mund të lexoni për këtë këtu.

GitLab

GitLab — njĂ« mjet i jetĂ«s sĂ« ciklit DevOps me burim tĂ« hapur, i cili pĂ«rfaqĂ«son njĂ« sistem menaxhimi tĂ« depozita tĂ« kodit pĂ«r Git me wiki tĂ« tij, sistemin e ndjekjes sĂ« gabimeve, pipeline CI/CD dhe funksione tĂ« tjera.

Para të filloni me realizimin e analizës së merge requesteve, duhet të regjistroheni dhe të ngarkoni projektin tuaj. Nëse nuk e dini si ta bëni këtë, unë sugjeroj artikull kolegu im.

Shënim. Mënyra e përshkruar më poshtë për konfigurimin e ambientit është një nga opsionet e mundshme. Qëllimi është të tregojmë hapat e konfigurimit të nevojshëm për analizë dhe aktivizimin e analizuesit. Në rastin tuaj, ndoshta do të jetë më e optimizuar ndarja e fazave të përgatitjes së ambientit (shtimi i depozitave, instalimi i analizuesit) dhe analizës: për shembull, përgatitja e imazheve Docker me ambientin e nevojshëm dhe përdorimi i tyre ose një mënyrë tjetër.

Për ta kuptuar më qartë se çfarë do të ndodhte tani, sugjeroj të hedhim një sy në diagramin e mëposhtëm:

Analiza e kërkesave për bashkim në GitLab me PVS-Studio për C#
Për funksionimin e analizuesit, kërkohet .NET Core SDK 3, kështu që para se të instaloni analizuesin, duhet të shtoni depozitat Microsoft, nga të cilat do të instalohen varësitë e nevojshme për analizuesin. Shtimi i depozitave Microsoft për distribucione të ndryshme Linux përshkruhet në dokumentin përkatës.

Për instalimin e PVS-Studio përmes menaxherit të paketave, gjithashtu do të nevojitet shtimi i depozitave PVS-Studio. Shtimi i depozitave për distribucione të ndryshme përshkruhet më hollësisht në seksionin përkatës të dokumentacionit.

Për funksionimin e analizuesit, nevojitet një çelës licence. Licencën provuese mund ta merrni në faqen e shkarkimit të analizuesit.

Shënim. Ju lutemi vini re se për modin e përshkruar të funksionimit (analiza e merge requests) nevojitet një licencë Enterprise. Prandaj, nëse dëshironi të provoni këtë mod, mos harroni të tregoni në fushën "Mesazh" se ju nevojitet pikërisht një licencë Enterprise.

Nëse ndodh një merge request, do të na nevojitet të analizojmë vetëm listën e skedareve të modifikuar; përndryshe analizojmë të gjitha skedaret. Pas analizës, duhet të konvertojmë logët në formatin e nevojshëm.

Tani, duke pasur përpara algoritmin e punës, mund të kalojmë në shkruarjen e skriptit. Për ta bërë këtë, nevojitet të ndryshoni skedarin .gitlab-ci.yml ose, nëse nuk ekziston, ta krijoni atë. Për ta krijuar, duhet të klikoni në emrin e projektit tuaj -> Caktoni CI/CD.

Analiza e kërkesave për bashkim në GitLab me PVS-Studio për C#
Tani jemi gati për të shkruar skriptin. Le të fillojmë së pari me kodin që do të instalojë analizuesin dhe do të fusë licencën:

para_script:
  - apt-get update && apt-get -y install wget gnupg 

  - apt-get -y install git
  - wget https://packages.microsoft.com/config/debian/10/
packages-microsoft-prod.deb -O packages-microsoft-prod.deb
  - dpkg -i packages-microsoft-prod.deb
  - apt-get update
  - apt-get install apt-transport-https
  - apt-get update
  
  - 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-dotnet

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY
  - dotnet restore "$CI_PROJECT_DIR"/Test/Test.sln

Pasiqë instalimi dhe aktivizimi duhet të ndodhin para të gjitha skripteve të tjera, ne përdorim një etiketë speciale before_script. Le të sqaroj këtë fragment pak.

Përgatitja për instalimin e analizatorit:

  - wget https://packages.microsoft.com/config/debian/10/
packages-microsoft-prod.deb -O packages-microsoft-prod.deb
  - dpkg -i packages-microsoft-prod.deb
  - apt-get update
  - apt-get install apt-transport-https
  - apt-get update

Shtimi i repositorëve PVS-Studio dhe analizatorit:

  - 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-dotnet

Aktivizimi i licencës:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME — emri i pĂ«rdoruesit.

$PVS_KEY — çelĂ«si i produktit.

RindĂ«rtimi i varĂ«sive tĂ« projektit, ku $CI_PROJECT_DIR – rruga e plotĂ« deri te dosja e projektit:

  - dotnet restore "$CI_PROJECT_DIR"/Path/To/Solution.sln

Për një analizë të saktë, projekti duhet të ndërtosh në mënyrë të suksesshme dhe varësitë e tij duhet të jenë ndërtuar (p.sh., paketat e nevojshme të NuGet duhet të jenë ngarkuar).

Krijimi i variablave tĂ« ambientit qĂ« pĂ«rmbajnĂ« informacionin e licencĂ«s mund tĂ« bĂ«het duke klikuar nĂ« CilĂ«simet, dhe pastaj — nĂ« CI / CD.

Analiza e kërkesave për bashkim në GitLab me PVS-Studio për C#
Në dritaren e hapur gjejmë pikën Variablat, në anën e djathtë klikojmë në butonin Zgjero dhe shtojmë variablat. Si rezultat, duhet të rezultojë si më poshtë:

Analiza e kërkesave për bashkim në GitLab me PVS-Studio për C#
Tani mund të vazhdojmë me analizën. Fillimisht, shtojmë skriptin për analizën e plotë. Në flamur -t përçojmë rrugën deri te zgjidhja, në flamur -o shkruajmë rrugën deri te skedari në të cilin do të regjistrohen rezultatet e analizës. Gjithashtu na intereson kodi i kthimit. Në këtë rast, na intereson që puna të ndalet kur kodi i kthimit përmban informacion se gjatë analizës janë dhënë paralajmërime. Kështu duket ky fragment:

job:
  script:
  - exit_code=0
  - pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -o PVS-Studio.json || exit_code=$?
  - exit_code=$((($exit_code & 8)/8))
  - if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi

Kodet e kthimit funksionojnĂ« sipas parimit tĂ« maskĂ«s bitore. PĂ«r shembull, nĂ«se gjatĂ« analizĂ«s u jepnin paralajmĂ«rime, kodi i kthimit do tĂ« jetĂ« 8. NĂ«se licenca skadon brenda njĂ« muaji, kodi i kthimit do tĂ« jetĂ« 4. NĂ«se gjatĂ« analizĂ«s u zbuluan gabime, si dhe licenca skadon brenda njĂ« muaji, nĂ« kodin e kthimit do tĂ« regjistrohen tĂ« dy vlerat: bashkojmĂ« numrat dhe marrim kodin e fundit tĂ« kthimit — 8+4=12. Pra, duke kontrolluar bitet pĂ«rkatĂ«se, mund tĂ« marrim informacion mbi gjendje tĂ« ndryshme gjatĂ« analizĂ«s. Kodet e kthimit pĂ«rshkruhen mĂ« nĂ« detaje nĂ« seksionin "Kodet e kthimit pvs-studio-dotnet (Linux / macOS)" tĂ« dokumentit.Kontrollimi i projekteve Visual Studio / MSBuild / .NET Core nga komanda e linjĂ«s me PVS-Studio".

Në këtë rast, na interesojnë të gjitha kodet e kthimit ku figuron 8.

  - exit_code=$((($exit_code & 8)/8))

Mund të marrim 1, kur kodi i kthimit përmban bitin që na intereson, përndryshe do të marrim 0.

Ka ardhur koha për të shtuar analizën e kërkesës për bashkimin. Para se ta bëjmë këtë, le të përgatitim vendin për skriptin. Na nevojitet që ai të ekzekutohet vetëm kur ndodh kërkesa për bashkimin. Kjo duket kështu:

merge:
  script:
  only:
  - merge_requests

Tani kalojmë në skriptin vetë. Kam hasur në faktin se makineria virtuale nuk di asgjë për origin/master. Prandaj e ndihmojmë pak:

  - git fetch origin

Tani do të marrim diferencën e degëve dhe do ta ruajmë rezultatin në txt file:

  - git diff --name-only origin/master $CI_COMMIT_SHA > pvs-fl.txt

Ku $CI_COMMIT_SHA – hash i komitit tĂ« fundit.

Më pas, fillojmë analizën e listës së skedarëve duke përdorur flakën --follow. Në të kalojmë skedarin .txt që morëm më herët. Ashtu si në analizën e plotë, shohim kodet e kthimit:

  - exit_code=0
  - pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -f 
pvs-fl.txt -o PVS-Studio.json || exit_code=$?
  - exit_code=$((($exit_code & 8)/8))
  - if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi

Skripti i plotë për kontrollin e kërkesës për bashkimin do të duket kështu:

merge:
  script:
  - git fetch origin
  - git diff --name-only origin/master $CI_COMMIT_SHA > pvs-fl.txt
  - exit_code=0
  - pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -f 
pvs-fl.txt -o PVS-Studio.json || exit_code=$?
  - exit_code=$((($exit_code & 8)/8))
  - if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi
  only:
  - merge_requests

Tani mbetet vetëm të shtojmë konvertimin e logut pasi kemi ekzekutuar të gjitha skriptet. Përdorim etiketën after_script dhe utilitarin plog-converter:

after_script:
  - plog-converter -t html -o eLog ./PVS-Studio.json

Mjeti plog-converter — Ă«shtĂ« njĂ« projekt open source, qĂ« pĂ«rdoret pĂ«r tĂ« kthyer raportin mbi gabimet e analizatorit nĂ« forma tĂ« ndryshme, pĂ«r shembull, HTML. NjĂ« pĂ«rshkrim mĂ« tĂ« detajuar tĂ« utilitarit gjendet nĂ« nĂ«nseksionin "Utilitari Plog Converter" seksioni pĂ«rkatĂ«s i dokumentacionit.

Tani, nëse dëshironi të punoni rehat me raportin .json lokal nga IDE, propozoj tonën plugin për IDE Rider. Përdorimi i tij përshkruhet më në detaj në dokumentin përkatës.

Për lehtësi, ja .gitlab-ci.yml në tërësi:

image: debian

before_script:
  - apt-get update && apt-get -y install wget gnupg 

  - apt-get -y install git
  - wget https://packages.microsoft.com/config/debian/10/
packages-microsoft-prod.deb -O packages-microsoft-prod.deb
  - dpkg -i packages-microsoft-prod.deb
  - apt-get update
  - apt-get install apt-transport-https
  - apt-get update
  
  - 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-dotnet

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY
  - dotnet restore "$CI_PROJECT_DIR"/Test/Test.sln

merge:
  script:
  - git fetch origin
  - git diff --name-only origin/master $CI_COMMIT_SHA > pvs-fl.txt
  - exit_code=0
  - pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -f 
pvs-fl.txt -o PVS-Studio.json || exit_code=$?
  - exit_code=$((($exit_code & 8)/8))
  - if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi
  only:
  - merge_requests

job:
  script:
  - exit_code=0
  - pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -o 
PVS-Studio.json || exit_code=$?
  - exit_code=$((($exit_code & 8)/8))
  - if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi
  
after_script:
  - plog-converter -t html -o eLog ./PVS-Studio.json

Sapo të kemi shtuar gjithçka në skedarin, klikojmë në Commit changes. Për të parë nëse gjithçka është siç duhet, hyni në CI/CD -> Pipeline -> Running. Një dritare virtuale do të hapet, në fund të së cilës duhet të jetë e tillë:

Analiza e kërkesave për bashkim në GitLab me PVS-Studio për C#
PamĂ« Job succeeded – sukses, gjithçka shkĂ«lqyer. Tani mund edhe tĂ« testojmĂ« atĂ« qĂ« Ă«shtĂ« bĂ«rĂ«.

Shembuj që punojnë

Për shembullin e punës, do të krijojmë një projekt të thjeshtë (në master) në të cilin do të jetë disa skeda. Pas kësaj, në një degë tjetër do të ndryshojmë vetëm një skedë dhe do të përpiqemi të bëjmë kërkesë për bashkim.

Le të shqyrtojmë dy raste: kur skeda e ndryshuar përmban një gabim dhe kur nuk ka. Së pari një shembull me gabim.

Supozoni se nĂ« degĂ«n master ka njĂ« skedĂ« Program.cs, e cila nuk pĂ«rmban gabime, ndĂ«rsa nĂ« njĂ« degĂ« tjetĂ«r zhvilluesi ka shtuar kod me gabim dhe dĂ«shiron tĂ« bĂ«jĂ« kĂ«rkesĂ« pĂ«r bashkim. E rĂ«ndĂ«sishme se çfarĂ« gabimi ka bĂ«rĂ« – nuk ka rĂ«ndĂ«si, e rĂ«ndĂ«sishme Ă«shtĂ« qĂ« ai Ă«shtĂ« atje. PĂ«r shembull, ka harruar operatorin throw (po, kaq ndodhin gabimet):

void MyAwesomeMethod(String name)
{
  if (name == null)
    new ArgumentNullException(....);
  // bëj diçka
  ....
}

Le të shohim rezultatin e analizës së shembullit me gabim. Gjithashtu, për të siguruar se vetëm një skedë është analizuar, kam shtuar një flamur -r në linjën e ekzekutimit pvs-studio-dotnet:

Analiza e kërkesave për bashkim në GitLab me PVS-Studio për C#
Shikojmë se analizatori gjeti një gabim dhe nuk lejoj bashkimin e degëve.

Të kontrollojmë shembullin pa gabim. Rregullojmë kodin:

void MyAwesomeMethod(String name)
{
  if (name == null)
    throw new ArgumentNullException(....);
  // bëj diçka
  ....
}

Rezultatet e analizës së kërkesës për bashkim:

Analiza e kërkesave për bashkim në GitLab me PVS-Studio për C#
Siç shohim, nuk janë gjetur gabime dhe ekzekutimi i detyrës kaloi me sukses, që ne donim të verifikonim.

PĂ«rfundim

TĂ« filtrojmĂ« kodin e keq para bashkimit tĂ« degĂ«ve — Ă«shtĂ« shumĂ« e rehatshme dhe e kĂ«ndshme. Prandaj, nĂ«se pĂ«rdorni CI/CD, prova ndihmoni ta pĂ«rfshini njĂ« analizator statik pĂ«r kontrollin. Sidomos pasi qĂ« bĂ«het mjaft lehtĂ«.

Faleminderit për vëmendjen.

Analiza e kërkesave për bashkim në GitLab me PVS-Studio për C#
Nëse dëshironi të ndani këtë artikull me publikun anglishtfolës, ju lutem përdorni lidhjen për përkthimin: Nikolay Mironov. Analiza e kërkesave për bashkim në GitLab duke përdorur PVS-Studio për C#.

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