Analiza e kërkesave për bashkim në GitLab duke përdorur PVS-Studio për C#

Ju pëlqen GitLab dhe urreni gabimet? Dëshironi të përmirësoni cilësinë e kodit tuaj burimor? Atëherë ju keni ardhur në vendin e duhur. Sot do t'ju tregojmë se si të konfiguroni analizuesin PVS-Studio C# për të kontrolluar kërkesat për bashkim. Keni një humor njëbrirësh dhe lexim të lumtur për të gjithë.

Studio PVS — është një mjet për identifikimin e gabimeve dhe dobësive të mundshme në kodin burimor të programeve të shkruara në C, C++, C# dhe Java. Funksionon në sisteme 64-bitëshe. Windows, Linux и macOSMund të analizojë kodin që synon platformat 32-bit, 64-bit dhe të ngulitura ARM.

Nga rruga, ne lëshuam PVS-Studio 7.08, në të cilin bëmë shumë gjëra interesante. Për shembull:

• Analizuesi C# nën Linux и macOS;
• plugin për Rider;
• modaliteti i kontrollit të listës së skedarëve të ri.

Mënyra e kontrollit të listës së skedarëve

Më parë, për të kontrolluar skedarë të caktuar, ishte e nevojshme që analizuesi të kalonte një .xml me një listë skedarësh. Por duke qenë se kjo nuk është shumë e përshtatshme, ne kemi shtuar mundësinë e transferimit të .txt, gjë që e bën jetën shumë të thjeshtë.

Për të kontrolluar skedarë të veçantë, duhet të specifikoni flamurin --sourceFiles (-f) dhe transferoni .txt me një listë skedarësh. Duket kështu:

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

Nëse jeni të interesuar të konfiguroni kërkesat e kontrollit ose tërheqjes së kryerjes, mund ta bëni këtë duke përdorur këtë modalitet. Dallimi do të jetë në marrjen e një liste skedarësh për t'u analizuar dhe do të varet nga sistemet që përdorni.

Parimi i kontrollit të një kërkese për bashkim

Thelbi kryesor i kontrollit është të sigurohet që problemet e zbuluara nga analizuesi gjatë bashkimit të mos bien në mjeshtër degë. Ne gjithashtu nuk duam të analizojmë të gjithë projektin çdo herë. Për më tepër, kur bashkojmë degët, kemi një listë të skedarëve të ndryshuar. Prandaj, unë sugjeroj të shtoni një kontroll të kërkesës për bashkim.

Kjo është se si duket një kërkesë për bashkim përpara se të zbatohet një analizues statik:

Kjo është, të gjitha gabimet që ishin në degë ndryshimet, do të kalojë në degën master. Meqenëse nuk do ta dëshironim këtë, shtojmë analizën dhe tani diagrami duket si ky:

Ne analizojmë ndryshimet2 dhe, nëse nuk ka gabime, ne e pranojmë kërkesën për bashkim, përndryshe e refuzojmë.

Nga rruga, nëse jeni të interesuar të analizoni angazhimet dhe të tërheqni kërkesat për C/C++, atëherë mund të lexoni për të këtu.

GitLab

GitLab është një mjet i ciklit të jetës së DevOps me burim të hapur, i bazuar në ueb, që ofron një sistem të menaxhimit të depove të kodeve për Git me wiki-n e tij, sistemin e gjurmimit të çështjeve, tubacionin CI/CD dhe veçori të tjera.

Përpara se të filloni të analizoni kërkesat për bashkim, duhet të regjistroheni dhe të ngarkoni projektin tuaj. Nëse nuk dini si ta bëni këtë, atëherë ju sugjeroj një artikull kolegu im.

Shënim. Metoda e konfigurimit të mjedisit të përshkruar më poshtë është një nga ato të mundshmet. Qëllimi është të tregohen hapat për vendosjen e mjedisit të nevojshëm për analizë dhe lëshimin e analizuesit. Ndoshta në rastin tuaj do të ishte më optimale të ndani fazat e përgatitjes së mjedisit (shtimi i depove, instalimi i një analizuesi) dhe analiza: për shembull, përgatitja e imazheve Docker me mjedisin e nevojshëm dhe përdorimi i tyre, ose ndonjë metodë tjetër.

Për të kuptuar më mirë se çfarë do të ndodhë tani, unë sugjeroj të shikoni diagramin e mëposhtëm:

Analizuesi kërkon .NET Core SDK 3, kështu që para se ta instaloni analizuesin, duhet të shtoni depot e Microsoft-it nga të cilat do të instalohen varësitë e analizuesit. Shtimi i depove të Microsoft-it për shpërndarje të ndryshme. Linux përshkruar në dokumentin përkatës.

Për të instaluar PVS-Studio përmes menaxherit të paketave, do t'ju duhet gjithashtu të shtoni magazinat PVS-Studio. Shtimi i depove për shpërndarje të ndryshme përshkruhet më në detaje në seksionin përkatës të dokumentacionit.

Analizuesi kërkon një çelës licence për të funksionuar. Ju mund të merrni një licencë prove në Faqja e shkarkimit të analizuesit.

Shënim. Ju lutemi vini re se mënyra e përshkruar e funksionimit (analiza e kërkesave për bashkim) kërkon një licencë të Ndërmarrjes. Prandaj, nëse dëshironi të provoni këtë mënyrë funksionimi, mos harroni të tregoni në fushën "Mesazhi" se ju nevojitet një licencë e Ndërmarrjes.

Nëse ndodh një kërkesë për bashkim, atëherë duhet vetëm të analizojmë listën e skedarëve të ndryshuar, përndryshe analizojmë të gjithë skedarët. Pas analizës, ne duhet të konvertojmë regjistrat në formatin që na nevojitet.

Tani, duke pasur para syve algoritmin e punës, mund të kaloni në shkrimin e një skenari. Për ta bërë këtë, duhet të ndryshoni skedarin .gitlab-ci.yml ose, nëse nuk ekziston, krijoni atë. Për ta krijuar atë, duhet të klikoni në emrin e projektit tuaj -> Konfiguro CI/CD.

Tani jemi gati të shkruajmë skenarin. Le të shkruajmë së pari kodin që do të instalojë analizuesin dhe të futim 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

Meqenëse instalimi dhe aktivizimi duhet të ndodhë përpara të gjithë skripteve të tjera, ne përdorim një etiketë të veçantë para_shkrimit. Më lejoni ta shpjegoj pak këtë fragment.

Përgatitja për të instaluar analizuesin:

  - 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 depove dhe analizuesit PVS-Studio:

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

Rikuperimi i varësive të projektit ku $CI_PROJECT_DIR – shtegu i plotë për në direktorinë e projektit:

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

Për analizë të saktë, projekti duhet të ndërtohet me sukses, dhe varësitë e tij duhet të rikthehen (për shembull, duhet të shkarkohen paketat e nevojshme NuGet).

Mund të vendosni variablat e mjedisit që përmbajnë informacione të licencës duke klikuar Vendosja, dhe pas - në CI/CD.

Në dritaren që hapet, gjeni artikullin Variablat, klikoni në butonin në të djathtë Expand dhe shtoni variabla. Rezultati duhet të duket si ky:

Tani mund të kaloni në analizë. Së pari, le të shtojmë një skenar për një analizë të plotë. Tek flamuri -t kalojmë rrugën drejt zgjidhjes së flamurit -o shkruani rrugën e skedarit në të cilin do të shkruhen rezultatet e analizës. Ne jemi të interesuar edhe për kodin e kthimit. Në këtë rast, ne jemi të interesuar që operacioni të ndalojë kur kodi i kthimit përmban informacion që paralajmërimet janë lëshuar 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

Kodet e kthimit funksionojnë sipas parimit të maskës bit. Për shembull, nëse analiza rezultoi në 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 analiza zbuloi gabime dhe licenca skadon brenda një muaji, kodi i kthimit do të përmbajë të dyja vlerat: mblidhni numrat së bashku për të marrë kodin përfundimtar të kthimit - 8 + 4 = 12. Kështu, duke kontrolluar bitët përkatës, mund të merrni informacion në lidhje me gjendje të ndryshme gjatë analizës. Kodet e kthimit përshkruhen më hollësisht në seksionin "Kodet e Kthimit pvs-studio-dotnet".Linux / macOS)" dokument "Kontrollimi i projekteve Visual Studio / MSBuild / .NET Core nga linja e komandës duke përdorur PVS-Studio".

Në këtë rast, ne jemi të interesuar për të gjitha kodet e kthimit ku shfaqet 8.

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

Ne do të marrim 1 kur kodi i kthimit të përmbajë bitin e numrit që na intereson, përndryshe do të marrim 0.

Është koha për të shtuar analizën e kërkesës për bashkim. Përpara se ta bëjmë këtë, le të përgatisim një vend për skenarin. Na duhet që të ekzekutohet vetëm kur të ndodhë një kërkesë për bashkim. Duket kështu:

merge:
  script:
  only:
  - merge_requests

Le të kalojmë te vetë skenari. U përballa me faktin se makina virtuale nuk di asgjë origjinë/mjeshtër. Pra, le ta ndihmojmë atë pak:

  - git fetch origin

Tani marrim ndryshimin midis degëve dhe ruajmë rezultatin në të txt dosje:

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

ku $CI_COMMIT_SHA – hash i kryerjes së fundit.

Më pas, fillojmë të analizojmë listën e skedarëve duke përdorur flamurin -f. Ne transferojmë në të skedarin .txt të marrë më parë. Epo, në analogji me analizën e plotë, ne 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 kontrollimin e një kërkese për bashkim 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

Gjithçka që mbetet është të shtoni konvertimin e regjistrit pasi të jenë përpunuar të gjitha skriptet. Ne përdorim etiketën pas_skriptit dhe dobia plog-konverter:

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

Shërbim plog-konverter është një projekt me burim të hapur që përdoret për të kthyer raportet e gabimeve të analizuesit në forma të ndryshme, si p.sh. HTML. Një përshkrim më i detajuar i mjetit është dhënë në nënseksionin "Plog Converter Utility" seksionin përkatës të dokumentacionit.

Nga rruga, nëse doni të punoni me lehtësi me raportet .json në nivel lokal nga IDE, atëherë unë sugjeroj tonë plugin për IDE Rider. Përdorimi i tij përshkruhet më në detaje në dokumentin përkatës.

Për lehtësi, ja ku është .gitlab-ci.yml në mënyrë të 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ë skedar, klikoni mbi Kryeni ndryshime. Për të parë se gjithçka është e saktë, shkoni te CI / CD -> tubacionet -> drejtimin. Do të hapet një dritare e makinës virtuale, në fund të së cilës duhet të ketë sa vijon:

pa Jobi ia doli - Suksese, gjithçka është në rregull. Tani mund të provoni atë që keni bërë.

Shembuj pune

Për një shembull pune, le të krijojmë një projekt të thjeshtë (në mjeshtër) i cili do të përmbajë disa skedarë. Pas kësaj, në një degë tjetër do të ndryshojmë vetëm një skedar dhe do të përpiqemi të bëjmë një kërkesë për bashkim.

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

Le të themi se ka një skedar në degën master Programi.cs, i cili nuk përmban gabime, por në një degë tjetër zhvilluesi shtoi kod të gabuar dhe dëshiron të bëjë një kërkesë për bashkim. Se çfarë lloj gabimi bëri nuk është aq e rëndësishme, gjëja kryesore është se ekziston. Për shembull, operatori harroi hedh (Po, shume gabim):

void MyAwesomeMethod(String name)
{
  if (name == null)
    new ArgumentNullException(....);
  // do something
  ....
}

Le të shohim rezultatin e analizimit të një shembulli me një gabim. Gjithashtu për t'u siguruar që vetëm një skedar ishte analizuar, shtova flamurin -r në linjën e nisjes pvs-studio-dotnet:

Ne shohim që analizuesi gjeti një gabim dhe nuk lejoi bashkimin e degëve.

Le të kontrollojmë shembullin pa gabim. Korrigjimi i kodit:

void MyAwesomeMethod(String name)
{
  if (name == null)
    throw new ArgumentNullException(....);
  // do something
  ....
}

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

Siç mund ta shohim, nuk u gjetën gabime dhe ekzekutimi i detyrës ishte i suksesshëm, gjë që ne donim të kontrollonim.

Përfundim

Heqja e kodit të keq përpara bashkimit të degëve është shumë e përshtatshme dhe e këndshme. Pra, nëse jeni duke përdorur CI/CD, provoni të futni një analizues statik për ta kontrolluar. Për më tepër, kjo është bërë mjaft thjesht.

Faleminderit për vëmendjen tuaj.

Nëse dëshironi ta ndani këtë artikull me një audiencë anglishtfolëse, ju lutemi përdorni lidhjen e përkthimit: Nikolay Mironov. Analiza e kërkesave për bashkim në GitLab duke përdorur PVS-Studio për C#.

Burimi: www.habr.com