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

Analiza e kërkesave për bashkim në GitLab me PVS-Studio për C#
A e dashur GitLab dhe nuk e doni gabimin? A dëshironi të përmirësoni cilësinë e kodit burimor? Atëherë keni ardhur në vendin e duhur. Sot do t'ju tregojmë si të konfiguroni analizuesin C# PVS-Studio për të kontrolluar kërkesat e bashkimit. Të gjithë me humor unicorn dhe lexim të këndshëm.

PVS-Studio — Ă«shtĂ« njĂ« mjet pĂ«r identifikimin e gabimeve dhe dobĂ«sive potenciale 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. Mund tĂ« analizojĂ« kodin e destinuar pĂ«r platformat 32-bit, 64-bit dhe ARM tĂ« integruara.

P.S., kemi lëshuar PVS-Studio 7.08, në të cilin kemi bërë shumë gjëra interesante. Për shembull:

  • analizuesi C# pĂ«r Linux dhe macOS;
  • plugin pĂ«r Rider;
  • modaliteti i ri pĂ«r kontrollimin e listĂ«s sĂ« skedarĂ«ve.

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

Më parë, për të kontrolluar skedarë të caktuar, ishte e nevojshme të dërgonit një .xml me listën e skedarëve në analizues. Por, duke qenë se kjo nuk ishte shumë e përshtatshme, ne Shtuar mundësinë e dërgimit të .txt, gjë që e thjeshton shumë jetën.

PĂ«r tĂ« kontrolluar skedarĂ« tĂ« caktuar, Ă«shtĂ« e nevojshme tĂ« tregoni flamurin —sourceFiles (-f) dhe tĂ« dĂ«rgoni .txt me listĂ«n e skedarĂ«ve. Kjo duket si vijon:

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

Nëse jeni të interesuar të konfiguroni kontrollin e komiteteve ose kërkesave për të bashkuar, mund ta bëni këtë duke përdorur këtë modalitet. Ndryshimi do të jetë në marrjen e një liste skedash për analizë dhe do të varet nga sistemet që përdorni.

Parimi i kontrollit të kërkesës për bashkim

Thelbi i kontrollit është që problemet e zbuluara nga analizatori të mos kalojnë në master degen. Gjithashtu, nuk duam që të analizojmë projektin në tërësi çdo herë. Veçanarisht kur kemi një listë skedash të ndryshuara gjatë bashkimit të degeve. Prandaj, sugjeroj të shtojmë kontrollin e kërkesës për bashkim.

Këtu është si duket kërkesa për bashkim para se të implementohet analizatori statik:

Analiza e kërkesave për bashkim në GitLab me PVS-Studio për C#
Domethënë, të gjitha gabimet që ishin në degën ndryshime, do të kalojnë në degën kryesore. Duke qenë se nuk do të dëshironim këtë, 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 s'ka gabime, pranojmë kërkesën për bashkim, në të kundërt e refuzojmë atë.

Për më tepër, nëse jeni të interesuar për analizën e komiteteve dhe kërkesave për bashkim për C/C++, mund të lexoni për këtë. këtu.

GitLab

GitLab — njĂ« mjet pĂ«r ciklin e jetĂ«s DevOps me burim tĂ« hapur, qĂ« paraqet njĂ« sistem menaxhimi tĂ« depove tĂ« kodit pĂ«r Git me wiki tĂ« vetĂ«n, sistem pĂ«r ndjekjen e gabimeve, pipeline CI/CD dhe funksione tĂ« tjera.

Para se të filloni të realizoni analizën e kërkesave për bashkim, është e nevojshme të regjistroheni dhe të ngarkoni projektin tuaj. Nëse nuk e dini si ta bëni këtë, ju sugjeroj artikullin kolegun tim.

Shënim. Mënyra e përshkruar më poshtë për konfigurimin e mjedisit është një nga mundësitë. Qëllimi është të tregojmë hapat e konfigurimit të mjedisit të nevojshëm për analizë dhe ekzekutimin e analizuesit. Ndoshta, në rastin tuaj, do të ishte më optimal të ndaheshin etapat e përgatitjes së mjedisit (shtimi i depove, instalimi i analizuesit) dhe analizës: për shembull, përgatitja e imazheve Docker me mjedisin e nevojshëm dhe përdorimi i tyre ose ndonjë mënyrë tjetër.

Për të kuptuar më qartë se çfarë do të ndodhë tani, ju sugjeroj të shikoni skemën e mëposhtme:

Analiza e kërkesave për bashkim në GitLab me PVS-Studio për C#
Për të funksionuar, analizatori ka nevojë për .NET Core SDK 3, prandaj para instalimit të analizatorit, duhet të shtoni repozitoret e Microsoft, prej nga do të instalohen varësitë e nevojshme për analizatorin. Shtimi i repozitoreve të Microsoft për shpërndarje të ndryshme Linux është përshkruar në dokumentin përkatës.

Për të instaluar PVS-Studio përmes menaxherit të paketave gjithashtu do të nevojitet të shtoni repozitoret PVS-Studio. Shtimi i repozitoreve për shpërndarje të ndryshme është përshkruar më në detaje në seksionin përkatës të dokumentacionit.

Për të funksionuar, analizatori kërkon një çelës licencimi. Mund të merrni një licencë provuese në faqen e shkarkimit të analizatorit.

Shënim. Vini re se për mënyrën e përshkruar të funksionimit (analizimi i merge requests) nevojitet një licencë Enterprise. Prandaj, nëse dëshironi të provoni këtë mënyrë funksionimi, në fushën "Mesazh" mos harroni të specifikoni se ju nevojitet pikërisht licenca Enterprise.

Nëse ndodh një merge request, do të na nevojitet të analizojmë vetëm listën e skedarëve të ndryshuar, ndryshe do të analizojmë të gjitha skedarët. Pas analizës, duhet të konvertojmë log-ët në formatin që na nevojitet.

Tani, me algoritmin e punës para syve, mund të kalojmë në shkruarjen e skriptit. Për ta bërë këtë, duhet të ndryshojmë skedarin .gitlab-ci.yml ose, nëse nuk ekziston, ta krijojmë atë. Për ta krijuar, duhen ndjekur këto hapa: klikoni mbi emrin e projektit tuaj -> Set up 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ë duke shkruar kodin që do të instaloje analistin dhe do të vendosë licencën:

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

Duke qenë se instalimi dhe aktivizimi duhet të ndodhin para çdo skripti tjetër, do të përdorim një etiketë speciale before_script. Do të shpjegoj pak këtë fragment.

Përgatitja për instalimin e analistit:

  - 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 analistit:

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

Rivendosja e varĂ«sive tĂ« projektit, ku $CI_PROJECT_DIR – rruga e plotĂ« deri nĂ« direktorinĂ« e projektit:

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

Për një analizë të saktë, projekti duhet të njihet si i suksesshëm dhe varësitë e tij duhet të jenë rivendosur (p.sh., paketat e nevojshme NuGet duhet të jenë shkarkuar).

Variablat e mjedisit, qĂ« pĂ«rmbajnĂ« informacionin e licencĂ«s, mund tĂ« vendosen duke klikuar mbi CilĂ«simet, dhe mĂ« pas — mbi CI / CD.

Analiza e kërkesave për bashkim në GitLab me PVS-Studio për C#
Në dritaren që hapet, gjejmë pikën Variablat, në anën e djathtë klikojmë butonin Zgjero dhe shtojmë variablat. Në fund, duhet të rezultojë kjo:

Analiza e kërkesave për bashkim në GitLab me PVS-Studio për C#
Tani mund të kalojmë në analizë. Së pari, do të shtojmë skriptin për analizën e plotë. Në flamur -t kaluar rrugën deri në solution, në flamur -o ne jemi rrugën deri te skedari ku do të ruhen rezultatet e analizës. Na intereson gjithashtu kodi i rikthimit. Në këtë rast, na intereson që puna të ndalojë kur kodi i rikthimit përmban informacion për ndonjë paralajmërim gjatë analizës. 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

Kode tĂ« rikthimit punojnĂ« sipas njĂ« principi tĂ« maskĂ«s bitore. PĂ«r shembull, nĂ«se gjatĂ« analizĂ«s janĂ« dhĂ«nĂ« paralajmĂ«rime, kodi i rikthimit do tĂ« jetĂ« 8. NĂ«se licenca skadon brenda njĂ« muaji, kodi i rikthimit do tĂ« jetĂ« 4. NĂ«se gjatĂ« analizĂ«s janĂ« zbuluar gabime dhe licenca skadon brenda njĂ« muaji, tĂ« dyja vlerat do tĂ« regjistrohen nĂ« kodin e rikthimit: gjithashtu numrat bashkohen dhe marrim kodin pĂ«rfundimtar tĂ« rikthimit — 8+4=12. KĂ«shtu, duke kontrolluar blloqet pĂ«rkatĂ«se, mund tĂ« merrni informacion rreth gjendjeve tĂ« ndryshme gjatĂ« analizĂ«s. MĂ« shumĂ« detaje rreth kodeve tĂ« rikthimit pĂ«rshkruhen nĂ« seksionin "Kode tĂ« rikthimit pvs-studio-dotnet (Linux / macOS)" tĂ« dokumentit "Kontrollimi i projekteve Visual Studio / MSBuild / .NET Core nga linja e komandĂ«s me PVS-Studio".

Në këtë rast, na interesojnë të gjitha kodet e kthimit që përfshijnë 8.

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

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

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

merge:
  script:
  only:
  - merge_requests

Të kalojmë te vetë skripti. Kam hasur në faktin se makina 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 fajl:

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

Ku $CI_COMMIT_SHA – hash-i i komitetit tĂ« fundit.

Më pas, nisi analizën e listës së dosjeve, duke përdorur flagun -f. Në të kalojmë dosjen .txt që e patëm më parë. Po ashtu me analizën e plotë shikojmë 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 bashkim do të duket kështu:

bash:
  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

Duhet vetëm të shtoni konvertimin e log-ut pasi të gjitha skriptet të kenë përfunduar. Përdorim etiketën after_script dhe utilitetin plog-converter:

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

Utilitari plog-converter — ky Ă«shtĂ« njĂ« projekt open source, i cili pĂ«rdoret pĂ«r tĂ« transformuar raportin e gabimeve tĂ« analizuesit nĂ« forma tĂ« ndryshme, pĂ«r shembull, HTML. NjĂ« pĂ«rshkrim mĂ« nĂ« detaje pĂ«r utilitetin Ă«shtĂ« dhĂ«nĂ« nĂ« nenin "Utiliteti i Plog Converter" tĂ« seksionit pĂ«rkatĂ«s tĂ« dokumentacionit.

Me këtë rast, nëse dëshironi të punoni lehtësisht me raportin .json lokalish nga IDE, ju propozoj tonin plugins për IDE Rider. Përdorimi i tij është përshkruar më në detaje në dokumentin përkatës.

Për lehtësi, ja .gitlab-ci.yml e plotë:

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

Pasi të keni shtuar gjithçka në skedarin, klikoni në Commit changes. Për të parë nëse gjithçka është në rregull, hyni në CI/CD -> Pipelines -> Running. Një dritare e makinës virtuale do të hapet, në fund të së cilës duhet të ketë këtë:

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

Shembuj pune

Për shembull, do të krijojmë një projekt të thjeshtë (në master) në të cilin do të ketë disa skedarë. Pas kësaj, në një degë tjetër do të ndryshojmë vetëm një skedar dhe do të provojmë të bëjmë një kërkesë për bashkim.

Le të shqyrtojmë dy raste: kur skedari i ndryshuar përmban një gabim dhe kur nuk përmban. Së pari, një shembull me gabim.

Supozoni se nĂ« degĂ«n master ka njĂ« skedar Program.cs, i cili nuk pĂ«rmban gabime, ndĂ«rsa nĂ« njĂ« degĂ« tjetĂ«r, zhvilluesi ka shtuar kod me gabim dhe dĂ«shiron tĂ« bĂ«jĂ« njĂ« kĂ«rkesĂ« pĂ«r bashkim. ÇfarĂ« lloji gabimi ka bĂ«rĂ« ai – nuk Ă«shtĂ« kaq e rĂ«ndĂ«sishme, e rĂ«ndĂ«sishme Ă«shtĂ« qĂ« ai ekziston. PĂ«rshembull, harroi operatorin throw (po, kĂ«shtu gabohen):

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

Të shohim rezultatin e analizës të shembullit me gabim. Gjithashtu, për t'u siguruar se vetëm një skedar është analizuar, kam shtuar një flag -r në linjën e komandës pvs-studio-dotnet:

Analiza e kërkesave për bashkim në GitLab me PVS-Studio për C#
Ne shohim se analiza ka gjetur një gabim dhe nuk ka lejuar bashkimin e degëve.

Të kontrollojmë shembullin pa gabim. Korrigjojmë 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ç shikojmë, gabime nuk u gjetën, dhe realizimi i detyrës kaloi me sukses, gjë që ne dëshironim të verifikonim.

Përfundimi

Filtrimi i kodit të keq para bashkimit të degëve është shumë i dobishëm dhe i këndshëm. Prandaj, nëse përdorni CI/CD, provoni të integroheni me një analizues statik për kontroll. Po ashtu, është e thjeshtë ta bëni këtë.

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 një audiencë anglishtfolëse, 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

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