🥇GitLab apvienošanas pieprasījumu analīze, izmantojot PVS-Studio C# valodā

Vai jums patīk GitLab, bet nepatīk kļūdas? Vēlaties uzlabot avota koda kvalitāti? Tad esat pareizajā vietā. Šodien mēs jums pastāstīsim, kā iestatīt C# PVS-Studio analizatoru merge request pārbaudei. Novēlam visiem burvīgu noskaņu un patīkamu lasīšanu.

PVS-Studio ir rīks, lai identificētu kļūdas un potenciālās ievainojamības programmatūras avota kodā, kas rakstīts C, C++, C# un Java valodās. Tas darbojas 64 bitu sistēmās Windows, Linux un macOS, un var analizēt kodu, kas paredzēts 32 bitu, 64 bitu un iebūvētiem ARM platformām.

Starp citu, mums ir iznācis PVS-Studio 7.08, kurā mēs esam paveikuši daudz interesanta interesantā. Piemēram:

C# analizators Linux un macOS;
spraudnis Rider;
jauns failu saraksta pārbaudes režīms.

Failu saraksta pārbaudes režīms

Iepriekš, lai pārbaudītu noteiktus failus, bija nepieciešams nodefinēt analizatoram .xml failu ar failu sarakstu. Taču tā kā tas nebija ļoti ērti, mēs pievienojām iespēju izmantot .txt failus, kas ļoti atvieglo dzīvi.

Lai pārbaudītu noteiktus failus, jānorāda karogs --sourceFiles (-f) un jānodod .txt fails ar failu sarakstu. Tas izskatās šādi:

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

Ja jūs interesē iestatīt pārbaudi komitejām vai pull requestiem, jūs to varat izdarīt, izmantojot šo režīmu. Atšķirība būs saistīta ar failu saraksta iegūšanu analīzei un atkarēsies no izmantotajām sistēmām.

Merge request pārbaudes princips

Pamats pārbaudei ir novērst analīzes laikā atklātās problēmas no nonākšanas master zarā. Turklāt mēs nevēlamies katru reizi analizēt visu projektu. Jo īpaši, ka, apvienojot zarus, mums ir pieejams mainīto failu saraksts. Tādēļ esam iecerējuši pievienot merge request pārbaudi.

Tā izskatās merge request pirms statiskā analizatora ieviešanas:

Tas nozīmē, ka visas kļūdas, kas atradās zarā changes, nonāks galvenajā zarā. Tā kā tā mums nepatīk, pievienojam analīzi, un tagad shēma izskatās šādi:

Analizējam changes2 un, ja nav kļūdu, pieņemam merge request, pretējā gadījumā noraidām to.

Starp citu, ja jūs interesē komiteju un pull requestu analīze C/C++ valodā, jūs varat to izlasīt šeit.

GitLab

GitLab — atvērta koda DevOps dzīves cikla tīmekļa rīks, kas pārstāv kodu glabātuves pārvaldības sistēmu Git ar savu vikipēdiju, kļūdu izsekošanas sistēmu, CI/CD pipeline un citām funkcijām.

Pirms sākt analizēt merge requestus, ir nepieciešams reģistrēties un augšupielādēt savu projektu. Ja nezināt, kā to izdarīt, es piedāvāju rakstu no mana kolēģa.

Piezīme. Aprakstītais iestatījumu veids ir tikai viens no iespējamiem. Mērķis ir parādīt nepieciešamos soļus, lai izveidotu vidi analīzei un palaistu analizatoru. Iespējams, jūsu gadījumā optimālāka būs vides sagatavošanas posmu atdalīšana (glabātuves pievienošana, analizatora instalēšana) un analīzes veikšana, piemēram, sagatavojot Docker attēlus ar nepieciešamo vidi un tos izmantojot vai kādu citu veidu.

Lai labāk saprastu, kas notiks tālāk, es piedāvāju apskatīt nākamo shēmu:

Analizatoram ir nepieciešams .NET Core SDK 3, tāpēc pirms analizatora instalēšanas jāpieprasa Microsoft glabātnes, no kurām tiks instalētas analizatoram nepieciešamās atkarības. Microsoft glabātņu pievienošana dažādiem Linux izplatījumiem ir aprakstīta attiecīgajā dokumentā.

Lai instalētu PVS-Studio caur pakotņu pārvaldnieku, būs nepieciešams arī pievienot PVS-Studio glabātuves. Glabātuves pievienošana dažādiem izplatījumiem ir sīkāk aprakstīta attiecīgajā dokumentācijas daļā.

Analizatoram ir nepieciešams licencēšanas atslēga. Izmēģinājuma licenci var iegūt analizatora lejupielādes lapā.

Piezīme. Lūdzu, ņemiet vērā, ka, lai izmantotu aprakstīto darba režīmu (merge request analīze), ir nepieciešama Enterprise licence. Tāpēc, ja vēlaties izmēģināt šo darba režīmu, lauka "Ziņojums" neaizmirstiet norādīt, ka jums tieši nepieciešama Enterprise licence.

Ja notiek merge request, mums būs jāpēta tikai mainīto failu saraksts, citādi analizēsim visus failus. Pēc analīzes ir jāpārveido žurnāli vajadzīgajā formātā.

Tagad, redzot darbības algoritmu, varam pāriet pie skripta rakstīšanas. Lai to izdarītu, nepieciešams mainīt failu .gitlab-ci.yml vai, ja tāda nav, izveidot to. Lai to izveidotu, jānospiež uz jūsu projekta nosaukuma -> Iestatīt CI/CD.

Tagad mēs esam gatavi skripta rakstīšanai. Sāksim ar koda rakstīšanu, kas instalēs analizatoru un ievadīs 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ācija un aktivizācija jāveic pirms visiem citiem skriptiem, izmantosim īpašu atzīmi before_script. Nedaudz paskaidrošu šo fragmentu.

Sagatavošanās analizatora instalācijai:

  - 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 un analizatora repozitoriju 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ācija:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME — lietotājvārds.

$PVS_KEY — produkta atslēga.

Projekta atkarību atjaunošana, kur $CI_PROJECT_DIR – pilns ceļš uz projekta direktoriju:

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

Lai veiktu pareizu analīzi, projektam jābūt veiksmīgi sakompilētam un tā atkarībām jābūt atjaunotām (piemēram, ir jāiegūst nepieciešamie NuGet pakotnes).

Vides mainīgos, kas satur licences informāciju, var uzstādīt, noklikšķinot uz Setting, un pēc tam — uz CI / CD.

Atvērtajā logā atrodam sadaļu Variables, labajā pusē noklikšķinām uz pogas Expand un pievienojam mainīgos. Rezultātā tam jāizskatās šādi:

Tagad varam pāriet uz analīzi. Vispirms pievienosim skriptu pilnai analīzei. Karogā -t norādām ceļu uz risinājumu, karogā -o norādām ceļu uz failu, kurā tiks saglabāti analīzes rezultāti. Mūs arī interesē atgriezuma kods. Šajā gadījumā mums ir svarīgi, lai darbs tiktu pārtraukts, kad atgriezuma kodā ir informācija par to, ka analīzes laikā tika sniegtas brīdinājumi. Šādi izskatās šis fragments:

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 masku principa. Piemēram, ja analīzes rezultātā tika izsniegtas brīdinājumi, tad atgriešanas kods būs vienāds ar 8. Ja licences derīguma termiņš beigsies mēneša laikā, tad atgriešanas kods būs 4. Ja analīzes laikā tika atklātas kļūdas un licences derīguma termiņš beidzas mēneša laikā, atgriešanas kodā tiks ierakstītas abas vērtības: saskaitām skaitļus kopā un iegūstam gala atgriešanas kodu — 8+4=12. Tādējādi, pārbaudot attiecīgos bitus, varam iegūt informāciju par dažādām stāvokļa izmaiņām analīzes laikā. Sīkāk atgriešanas kodi tiek aprakstīti nodaļā "PVS-Studio atgriešanas kodi (Linux / macOS)" dokumentā "Visual Studio / MSBuild / .NET Core projektu pārbaude no komandrindas, izmantojot PVS-Studio".

Šajā gadījumā mūs interesē visi atgriešanas kodi, kuros ir 8.

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

Mēs iegūsim 1, kad atgriešanas kods satur mums interesējošo bitu, citādi iegūsim 0.

Ir pienācis laiks pievienot merge request analīzi. Pirms to izdarām, sagatavosim vietu skriptam. Mums ir jānodrošina, lai tas tiktu izpildīts tikai tad, kad notiek merge request. Izskatās tas šādi:

merge:
  script:
  only:
  - merge_requests

Pāriesim pie paša skripta. Es saskāros ar to, ka virtuālā mašīna neko nezina par origin/master. Tāpēc palīdzēsim tai nedaudz:

  - git fetch origin

Tagad iegūsim atšķirību starp zaru un saglabāsim rezultātu txt failā:

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

Kur $CI_COMMIT_SHA – pēdējā komitē heshs.

Pēc tam palaidīsim failu analīzi, izmantojot karogu -f. Tajā nododam iepriekš iegūto .txt failu. Nu un līdzīgi kā pilnīgā analīzē skatāmies 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 merge request 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

Paliek tikai pievienot žurnāla konvertāciju pēc tam, kad visi skripti ir izpildīti. Izmantosim birku after_script un utilītu plog-converter:

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

Rīks plog-converter ir open source projekts, kas tiek izmantots, lai pārveidotu analizatora kļūdu ziņojumu dažādās formās, piemēram, HTML. Plašāka informācija par utilītu ir sniegta apakšsadaļā "Plog Converter utilīta" attiecināmās dokumentācijas sadaļas.

Starp citu, ja vēlaties ērti strādāt ar .json ziņojumu lokāli no IDE, tad piedāvājam mūsu paplašinājumu IDE Rider. Plašāk par tā izmantošanu ir aprakstīts attiecināmajā dokumentā.

Ērtības labad lūk .gitlab-ci.yml veselumā:

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 esat pievienojuši visu failam, nospiediet uz Commit changes. Lai pārliecinātos, ka viss ir pareizi, dodamies uz CI/CD -> Pipelines -> Running. Atvērsies virtuālās mašīnas logs, kurā beigās jābūt sekojošam:

Redzējāt Job succeeded – izdevās, viss lieliski. Tagad var sākt testēt paveikto.

Darba piemēri

Piemēram, izveidosim vienkāršu projektu (kurā master) būs vairāki faili. Pēc tam citā zarā mainīsim tikai vienu failu un mēģināsim izveidot apvienošanas pieprasījumu.

Apskatīsim divas situācijas: kad mainītais fails satur kļūdu un kad nē. Sākumā piemērs ar kļūdu.

Pieņemsim, ka master zarā ir fails Program.cs, kas nesatur kļūdas, bet citā zarā izstrādātājs ir pievienojis kļūdainu kodu un vēlas izveidot apvienošanas pieprasījumu. Kuru tieši kļūdu viņš pieļāva – nav tik svarīgi, galvenais, ka tā ir. Piemēram, aizmirsis operatoru throw (jā, tā kļūdās):

void MyAwesomeMethod(String name)
{
  if (name == null)
    new ArgumentNullException(....);
  // darīt kaut ko
  ....
}

Apskatīsim analīzes rezultātus piemēram ar kļūdu. Lai pārliecinātos, ka tikai viens fails tika analizēts, es pievienoju karogu -r pvs-studio-dotnet palaišanas rindā:

Mēs redzam, ka analizators ir atradis kļūdu un neļāvis veikt zaru apvienošanu.

Pārbaudām piemēru bez kļūdām. Labojam kodu:

void MyAwesomeMethod(String name)
{
  if (name == null)
    throw new ArgumentNullException(....);
  // darīt kaut ko
  ....
}

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

Kā redzam, kļūdas nav atrastas un uzdevuma izpilde ir noritējusi veiksmīgi, ko arī vēlējāmies pārbaudīt.

Secinājums

Sliktā koda filtrēšana pirms zaru apvienošanas ir ļoti ērta un patīkama. Tāpēc, ja izmantojat CI/CD, mēģiniet iebūvēt statisko analizatoru pārbaudei. Jo to izdarīt ir diezgan vienkārši.

Paldies par uzmanību.

Ja vēlaties dalīties ar šo rakstu ar angliski runājošo auditoriju, lūdzu, izmantojiet saiti uz tulkojumu: Nikolay Mironov. Apvienošanas pieprasījumu analīze GitLab izmantojot PVS-Studio C#.

Avots: habr.com

Merge request analīze GitLab vidē ar PVS-Studio C# valodā

Failu saraksta pārbaudes režīms

Merge request pārbaudes princips

GitLab

Darba piemēri

Secinājums