🥇Apvienošanas pieprasījumu analīze GitLab, izmantojot PVS-Studio for C#

Vai jums patīk GitLab un ienīst kļūdas? Vai vēlaties uzlabot sava pirmkoda kvalitāti? Tad jūs esat nonācis īstajā vietā. Šodien mēs jums pateiksim, kā konfigurēt PVS-Studio C# analizatoru, lai pārbaudītu sapludināšanas pieprasījumus. Lai visiem vienradža noskaņojums un priecīga lasīšana.

PVS-studija ir rīks kļūdu un iespējamo ievainojamību identificēšanai C, C++, C# un Java valodā rakstīto programmu pirmkodā. Darbojas 64 bitu sistēmās operētājsistēmās Windows, Linux un macOS. Var analizēt kodu, kas paredzēts 32 bitu, 64 bitu un iegultajām ARM platformām.

Starp citu, mēs izlaidām PVS-Studio 7.08, kurā mēs darījām daudzas lietas interesanti. Piemēram:

C# analizators operētājsistēmai Linux un macOS;
spraudnis Rider;
jauna failu saraksta pārbaudes režīms.

Failu saraksta pārbaudes režīms

Iepriekš, lai pārbaudītu noteiktus failus, analizatoram bija jānodod .xml ar failu sarakstu. Bet, tā kā tas nav īpaši ērti, esam pievienojuši iespēju pārsūtīt .txt, kas padara dzīvi ļoti vienkāršu.

Lai pārbaudītu konkrētus failus, jānorāda karogs --avota faili (-f) un pārsūtiet .txt ar failu sarakstu. Tas izskatās šādi:

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

Ja vēlaties iestatīt saistību pārbaudes vai izvilkšanas pieprasījumus, varat arī to izdarīt, izmantojot šo režīmu. Atšķirība būs analizējamo failu saraksta iegūšana, un tā būs atkarīga no izmantotajām sistēmām.

Apvienošanas pieprasījuma pārbaudes princips

Pārbaudes galvenā būtība ir nodrošināt, lai analizatora sapludināšanas laikā atklātās problēmas neietilpst sistēmā meistars filiāle. Mēs arī nevēlamies katru reizi analizēt visu projektu. Turklāt, apvienojot filiāles, mums ir mainīto failu saraksts. Tāpēc es iesaku pievienot sapludināšanas pieprasījuma pārbaudi.

Šādi izskatās sapludināšanas pieprasījums pirms statiskā analizatora ieviešanas:

Tas ir, visas kļūdas, kas bija filiālē izmaiņas, pāries uz galveno filiāli. Tā kā mēs to negribētu, mēs pievienojam analīzi, un tagad diagramma izskatās šādi:

Mēs analizējam izmaiņas2 un, ja kļūdu nav, mēs pieņemam sapludināšanas pieprasījumu, pretējā gadījumā to noraidām.

Starp citu, ja jūs interesē C/C++ saistību un izvilkšanas pieprasījumu analīze, varat par to lasīt šeit.

GitLab

GitLab ir atvērtā pirmkoda tīmekļa DevOps dzīves cikla rīks, kas nodrošina Git kodu repozitorija pārvaldības sistēmu ar savu wiki, problēmu izsekošanas sistēmu, CI/CD konveijeru un citām funkcijām.

Pirms sākat analizēt sapludināšanas pieprasījumus, jums ir jāreģistrējas un jāaugšupielādē savs projekts. Ja jūs nezināt, kā to izdarīt, es iesaku raksts Mans kolēģis.

Piezīme. Tālāk aprakstītā vides izveides metode ir viena no iespējamām. Mērķis ir parādīt analīzei nepieciešamās vides iestatīšanas un analizatora palaišanas soļus. Varbūt jūsu gadījumā optimālāk būtu nodalīt vides sagatavošanas (repozitoriju pievienošana, analizatora uzstādīšana) un analīzes posmus: piemēram, Docker attēlu sagatavošana ar nepieciešamo vidi un to izmantošana vai kāda cita metode.

Lai labāk saprastu, kas tagad notiks, iesaku aplūkot šādu diagrammu:

Lai analizators darbotos, ir nepieciešams .NET Core SDK 3, tāpēc pirms analizatora instalēšanas ir jāpievieno Microsoft krātuves, no kurām tiks instalētas analizatoram nepieciešamās atkarības. Microsoft repozitoriju pievienošana dažādiem Linux izplatījumiem aprakstīts attiecīgajā dokumentā.

Lai instalētu PVS-Studio, izmantojot pakotņu pārvaldnieku, jums būs jāpievieno arī PVS-Studio krātuves. Repozitoriju pievienošana dažādiem izplatījumiem ir sīkāk aprakstīta rakstā attiecīgā dokumentācijas sadaļa.

Analizatora darbībai nepieciešama licences atslēga. Izmēģinājuma licenci varat iegūt vietnē analizatora lejupielādes lapa.

Piezīme. Lūdzu, ņemiet vērā, ka aprakstītajam darbības režīmam (apvienošanas pieprasījumu analīzei) ir nepieciešama uzņēmuma licence. Tāpēc, ja vēlaties izmēģināt šo darbības režīmu, neaizmirstiet laukā “Ziņojums” norādīt, ka jums ir nepieciešama uzņēmuma licence.

Ja rodas sapludināšanas pieprasījums, mums ir jāanalizē tikai mainīto failu saraksts, pretējā gadījumā mēs analizējam visus failus. Pēc analīzes mums ir jāpārvērš žurnāli vajadzīgajā formātā.

Tagad, kad jūsu acu priekšā ir darba algoritms, varat pāriet uz skripta rakstīšanu. Lai to izdarītu, jums ir jāmaina fails .gitlab-ci.yml vai, ja tā neeksistē, izveidojiet to. Lai to izveidotu, jānoklikšķina uz sava projekta nosaukuma -> Iestatiet CI/CD.

Tagad esam gatavi rakstīt scenāriju. Vispirms uzrakstīsim kodu, kas instalēs analizatoru, un ievadīsim licenci:

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

Tā kā instalēšanai un aktivizēšanai jānotiek pirms visiem citiem skriptiem, mēs izmantojam īpašu etiķeti pirms_skripta. Ļaujiet man nedaudz paskaidrot šo fragmentu.

Sagatavošanās analizatora uzstādīšanai:

  - 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

PVS-Studio repozitoriju un analizatora pievienošana:

  - 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

Licences aktivizēšana:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME - Lietotājvārds.

$PVS_KEY - produkta atslēga.

Projektu atkarību atgūšana kur $CI_PROJECT_DIR - pilns ceļš uz projekta direktoriju:

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

Lai veiktu pareizu analīzi, projekts ir sekmīgi jāizveido un jāatjauno tā atkarības (piemēram, jālejupielādē nepieciešamās NuGet pakotnes).

Varat iestatīt vides mainīgos, kas satur licences informāciju, noklikšķinot uz Iestatīšana, un pēc tam - ieslēgts CI/CD.

Atvērtajā logā atrodiet vienumu Mainīgie, noklikšķiniet uz pogas labajā pusē paplašināt un pievienojiet mainīgos. Rezultātam vajadzētu izskatīties šādi:

Tagad varat pāriet uz analīzi. Vispirms pievienosim skriptu pilnīgai analīzei. Uz karogu -t mēs ejam ceļu uz risinājumu karogam -o ierakstiet ceļu uz failu, kurā tiks ierakstīti analīzes rezultāti. Mūs interesē arī atgriešanas kods. Šajā gadījumā mēs esam ieinteresēti, lai darbība tiktu apturēta, kad atgriešanas kods satur informāciju, ka analīzes laikā tika izteikti brīdinājumi. Šis fragments izskatās šādi:

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

Atgriešanas kodi darbojas pēc bitu maskas principa. Piemēram, ja analīzes rezultātā tika izteikti brīdinājumi, tad atgriešanas kods būs vienāds ar 8. Ja licences derīguma termiņš beidzas mēneša laikā, tad atgriešanas kods būs vienāds ar 4. Ja analīzes laikā tika konstatētas kļūdas, un licence beidzas mēneša laikā, kods atgriežas, tiks ierakstītas abas vērtības: saskaitiet skaitļus un iegūstiet galīgo atgriešanas kodu - 8+4=12. Tādējādi, pārbaudot atbilstošos bitus, analīzes laikā var iegūt informāciju par dažādiem stāvokļiem. Sīkāk atgriešanas kodi ir aprakstīti dokumenta sadaļā "pvs-studio-dotnet (Linux / macOS) atgriešanas kodi".Visual Studio/MSBuild/.NET Core projektu pārbaude no komandrindas, izmantojot PVS-Studio".

Šajā gadījumā mūs interesē visi atgriešanas kodi, kur parādās 8.

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

Mēs saņemsim 1, kad atgriešanas kodā būs mūs interesējošā skaitļa bits, pretējā gadījumā mēs saņemsim 0.

Ir pienācis laiks pievienot sapludināšanas pieprasījuma analīzi. Pirms to darām, sagatavosim vietu skriptam. Mums tas ir jāizpilda tikai tad, kad notiek sapludināšanas pieprasījums. Tas izskatās šādi:

merge:
  script:
  only:
  - merge_requests

Pāriesim pie paša skripta. Es saskāros ar faktu, ka virtuālā mašīna neko nezina izcelsme/meistars. Palīdzēsim viņai mazliet:

  - git fetch origin

Tagad mēs iegūstam atšķirību starp zariem un saglabājam rezultātu txt fails:

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

Kur $CI_COMMIT_SHA – pēdējās apņemšanās hash.

Tālāk mēs sākam analizēt failu sarakstu, izmantojot karogu -f. Pārsūtām uz to iepriekš saņemto .txt failu. Nu, pēc analoģijas ar pilnu analīzi, mēs aplūkojam atgriešanas kodus:

  - 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

Pilns skripts sapludināšanas pieprasījuma pārbaudei izskatīsies šādi:

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

Atliek tikai pievienot žurnāla konvertēšanu pēc visu skriptu apstrādes. Mēs izmantojam etiķeti after_script un lietderība plog pārveidotājs:

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

Lietderība plog pārveidotājs ir atvērtā koda projekts, ko izmanto, lai pārveidotu parsētāja kļūdu ziņojumus dažādās formās, piemēram, HTML. Detalizētāks utilītas apraksts ir sniegts apakšsadaļā "Plog Converter Utility" attiecīgā dokumentācijas sadaļa.

Starp citu, ja vēlaties ērti strādāt ar .json ziņojumiem lokāli no IDE, es iesaku mūsu iespraust priekš IDE Rider. Tās lietošana ir sīkāk aprakstīta rakstā attiecīgais dokuments.

Ērtības labad tas ir šeit .gitlab-ci.yml pilnā apmērā:

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

Kad failam viss ir pievienots, noklikšķiniet uz Veiciet izmaiņas. Lai pārliecinātos, ka viss ir pareizi, dodieties uz CI / CD -> Cauruļvadi -> Ekspluatācijas. Tiks atvērts virtuālās mašīnas logs, kura beigās jābūt šādam:

ieraudzīja Darbam izdevās - veiksmi, viss kārtībā. Tagad jūs varat pārbaudīt paveikto.

Darba piemēri

Darba paraugam izveidosim vienkāršu projektu (in meistars), kurā būs vairāki faili. Pēc tam citā filiālē mēs mainīsim tikai vienu failu un mēģināsim veikt sapludināšanas pieprasījumu.

Apskatīsim divus gadījumus: kad modificētajā failā ir kļūda un kad tā nav. Pirmkārt, piemērs ar kļūdu.

Pieņemsim, ka galvenajā filiālē ir fails Programma.cs, kurā nav kļūdu, bet citā filiālē izstrādātājs pievienoja kļūdainu kodu un vēlas veikt sapludināšanas pieprasījumu. Tas, kādu kļūdu viņš pieļāva, nav tik svarīgi, galvenais, lai tā pastāv. Piemēram, operators aizmirsa mest (Jā, tik nepareizi):

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

Apskatīsim piemēra ar kļūdu analīzes rezultātu. Tāpat, lai pārliecinātos, ka ir parsēts tikai viens fails, es pievienoju karogu -r uz pvs-studio-dotnet palaišanas līniju:

Mēs redzam, ka analizators atrada kļūdu un neļāva apvienot filiāles.

Pārbaudīsim piemēru bez kļūdas. Koda labošana:

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

Apvienošanas pieprasījuma analīzes rezultāti:

Kā redzam, kļūdas netika atrastas, un uzdevuma izpilde bija veiksmīga, ko arī vēlējāmies pārbaudīt.

Secinājums

Sliktā koda atsijāšana pirms zaru sapludināšanas ir ļoti ērta un patīkama. Tātad, ja izmantojat CI/CD, mēģiniet iegult statisko analizatoru, lai pārbaudītu. Turklāt tas tiek darīts pavisam vienkārši.

Paldies par uzmanību.

Ja vēlaties dalīties ar šo rakstu ar angliski runājošu auditoriju, lūdzu, izmantojiet tulkošanas saiti: Nikolajs Mironovs. Apvienošanas pieprasījumu analīze pakalpojumā GitLab, izmantojot PVS-Studio for C#.

Avots: www.habr.com

Apvienošanas pieprasījumu analīze pakalpojumā GitLab, izmantojot PVS-Studio for C#

Failu saraksta pārbaudes režīms

Apvienošanas pieprasījuma pārbaudes princips

GitLab

Darba piemēri

Secinājums

Pievieno komentāru Atcelt atbildi