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

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

Bleni hostim të besueshëm për faqe me mbrojtje nga DDoS, serverë VPS VDS 🔥 Bleni hostim të besueshëm për faqe me mbrojtje nga DDoS, serverë VPS VDS | ProHoster