🥇Sujungimo užklausų analizė GitLab naudojant PVS-Studio for C#

Mėgstate „GitLab“ ir nekenčiate klaidų? Norite pagerinti šaltinio kodo kokybę? Tada jūs atėjote į reikiamą vietą. Šiandien mes jums pasakysime, kaip sukonfigūruoti PVS-Studio C# analizatorių, kad būtų galima patikrinti sujungimo užklausas. Vienaragiškos nuotaikos ir malonaus skaitymo visiems.

„PVS-Studio“ – tai įrankis, skirtas C, C++, C# ir Java kalbomis parašytų programų šaltinio kodo klaidoms ir galimiems pažeidžiamumams nustatyti. Jis veikia 64 bitų sistemose. Windows, Linux и macOSJis gali analizuoti kodą, skirtą 32 bitų, 64 bitų ir įterptosioms ARM platformoms.

Beje, mes išleidome PVS-Studio 7.08, kuriame padarėme daug dalykų įdomus. Pavyzdžiui:

C# analizatorius pagal Linux и macOS;
Rider įskiepis;
naujo failų sąrašo tikrinimo režimas.

Failų sąrašo tikrinimo režimas

Anksčiau, norint patikrinti tam tikrus failus, į analizatorių reikėdavo perduoti .xml su failų sąrašu. Bet kadangi tai nėra labai patogu, pridėjome galimybę perkelti .txt, o tai labai palengvina gyvenimą.

Norėdami patikrinti konkrečius failus, turite nurodyti vėliavėlę --sourceFiles (-f) ir perkelkite .txt su failų sąrašu. Tai atrodo taip:

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

Jei norite nustatyti įsipareigojimų tikrinimo arba ištraukimo užklausas, tai galite padaryti ir naudodami šį režimą. Skirtumas bus analizuojamų failų sąrašo sudarymas ir priklausys nuo to, kokias sistemas naudojate.

Sujungimo prašymo tikrinimo principas

Pagrindinė patikrinimo esmė yra užtikrinti, kad sujungimo metu analizatoriaus aptiktos problemos nepatektų į meistras šaka. Taip pat nenorime kiekvieną kartą analizuoti viso projekto. Be to, sujungdami filialus, turime pakeistų failų sąrašą. Todėl siūlau pridėti sujungimo užklausos patikrą.

Štai kaip atrodo sujungimo užklausa prieš diegiant statinį analizatorių:

Tai yra visos klaidos, kurios buvo filiale pakeitimai, persikels į pagrindinį filialą. Kadangi mes to nenorėtume, pridedame analizę, o dabar diagrama atrodo taip:

Analizuojant pokyčiai2 ir, jei nėra klaidų, sujungimo prašymą priimame, kitu atveju jį atmetame.

Beje, jei jus domina C/C++ įsipareigojimų ir ištraukimo užklausų analizė, galite apie tai paskaityti čia.

GitLab

GitLab yra atvirojo kodo žiniatinklio „DevOps“ gyvavimo ciklo įrankis, suteikiantis „Git“ kodų saugyklos valdymo sistemą su savo wiki, problemų sekimo sistema, CI / CD konvejeriu ir kitomis funkcijomis.

Prieš pradėdami analizuoti sujungimo užklausas, turite užsiregistruoti ir įkelti savo projektą. Jei nežinote, kaip tai padaryti, siūlau straipsnis Mano kolega.

Atkreipti dėmesį. Toliau aprašytas aplinkos nustatymo būdas yra vienas iš galimų. Tikslas – parodyti analizei reikalingos aplinkos sukūrimo ir analizatoriaus paleidimo žingsnius. Galbūt Jūsų atveju būtų optimaliau atskirti aplinkos paruošimo (repozitorijų papildymo, analizatoriaus įdiegimo) ir analizės etapus: pavyzdžiui, Docker vaizdų paruošimas su reikiama aplinka ir jų panaudojimas ar koks kitas būdas.

Norėdami geriau suprasti, kas dabar bus, siūlau pažvelgti į šią diagramą:

Analizatoriui reikalinga „.NET Core SDK 3“, todėl prieš diegdami analizatorių turite pridėti „Microsoft“ saugyklas, iš kurių bus įdiegtos analizatoriaus priklausomybės. „Microsoft“ saugyklų pridėjimas įvairiems platinimams. Linux aprašyta atitinkamame dokumente.

Norėdami įdiegti PVS-Studio per paketų tvarkyklę, taip pat turėsite pridėti PVS-Studio saugyklas. Įvairių platinimų saugyklų pridėjimas išsamiau aprašytas atitinkamą dokumentacijos skyrių.

Kad analizatorius veiktų, reikalingas licencijos raktas. Bandomąją licenciją galite gauti adresu analizatoriaus atsisiuntimo puslapis.

Atkreipti dėmesį. Atkreipkite dėmesį, kad aprašytam veikimo režimui (sujungimo užklausų analizei) reikalinga įmonės licencija. Todėl, jei norite išbandyti šį veikimo režimą, nepamirškite laukelyje „Pranešimas“ nurodyti, kad jums reikalinga įmonės licencija.

Jei įvyksta sujungimo užklausa, mums tereikia išanalizuoti pakeistų failų sąrašą, kitu atveju analizuojame visus failus. Atlikę analizę, turime konvertuoti žurnalus į mums reikalingą formatą.

Dabar, prieš akis turėdami darbo algoritmą, galite pereiti prie scenarijaus rašymo. Norėdami tai padaryti, turite pakeisti failą .gitlab-ci.yml arba, jei jo nėra, sukurkite jį. Norėdami jį sukurti, turite spustelėti savo projekto pavadinimą -> Nustatykite CI / CD.

Dabar esame pasiruošę rašyti scenarijų. Pirmiausia parašykite kodą, kuris įdiegs analizatorių ir įveskite licenciją:

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

Kadangi diegimas ir aktyvinimas turi įvykti prieš visus kitus scenarijus, naudojame specialią etiketę prieš_skriptą. Leiskite šiek tiek paaiškinti šį fragmentą.

Pasiruošimas montuoti analizatorių:

  - 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 saugyklų ir analizatoriaus pridėjimas:

  - 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

Licencijos aktyvinimas:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME - Vartotojo vardas.

$PVS_KEY - produkto raktas.

Projekto priklausomybių atkūrimas kur $CI_PROJECT_DIR – visas kelias į projekto katalogą:

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

Norint atlikti teisingą analizę, projektas turi būti sėkmingai sukurtas ir jo priklausomybės turi būti atkurtos (pavyzdžiui, reikia atsisiųsti reikiamus NuGet paketus).

Spustelėdami galite nustatyti aplinkos kintamuosius, kuriuose yra licencijos informacija nustatymas, o po – įjungta CI/CD.

Atsidariusiame lange raskite elementą Kintamieji, spustelėkite dešinėje esantį mygtuką Plėsti ir pridėkite kintamųjų. Rezultatas turėtų atrodyti taip:

Dabar galite pereiti prie analizės. Pirma, pridėkime scenarijų, skirtą išsamiai analizei. Prie vėliavos -t pereiname kelią į sprendimą iki vėliavos -o parašyti kelią į failą, kuriame bus rašomi analizės rezultatai. Mus taip pat domina grąžinimo kodas. Šiuo atveju esame suinteresuoti, kad operacija sustotų, kai grąžinimo kode pateikiama informacija, kad analizės metu buvo pateikti įspėjimai. Štai kaip atrodo šis fragmentas:

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

Grąžinimo kodai veikia bitų kaukės principu. Pavyzdžiui, jei analizės rezultatas buvo įspėjimai, grąžinimo kodas bus 8. Jei licencijos galiojimas baigiasi per mėnesį, grąžinimo kodas bus 4. Jei analizės metu aptikta klaidų ir licencijos galiojimas baigiasi per mėnesį, grąžinimo kode bus abi reikšmės: sudėkite skaičius, kad gautumėte galutinį grąžinimo kodą – 8 + 4 = 12. Taigi, patikrinę atitinkamus bitus, galite gauti informacijos apie įvairias būsenas analizės metu. Grąžinimo kodai išsamiau aprašyti skyriuje „pvs-studio-dotnet grąžinimo kodai“.Linux / macOS) „dokumentas“Visual Studio / MSBuild / .NET Core projektų tikrinimas iš komandinės eilutės naudojant PVS-Studio".

Šiuo atveju mus domina visi grąžinimo kodai, kuriuose yra 8.

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

1 gausime, kai grąžinimo kode bus mus dominančio skaičiaus bitas, kitu atveju gausime 0.

Atėjo laikas pridėti sujungimo užklausų analizę. Prieš tai darydami, paruošime vietą scenarijui. Mums reikia, kad jis būtų vykdomas tik tada, kai pateikiama sujungimo užklausa. Tai atrodo taip:

merge:
  script:
  only:
  - merge_requests

Pereikime prie paties scenarijaus. Aš susidūriau su tuo, kad virtuali mašina nieko nežino kilmė / meistras. Taigi padėkime jai šiek tiek:

  - git fetch origin

Dabar gauname skirtumą tarp šakų ir išsaugome rezultatą txt failas:

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

kur $CI_COMMIT_SHA – paskutinio įsipareigojimo maiša.

Tada mes pradedame analizuoti failų sąrašą naudodami vėliavėlę -f. Į jį perkeliame anksčiau gautą .txt failą. Na, pagal analogiją su visa analize, mes žiūrime į grąžinimo 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

Visas sujungimo užklausos tikrinimo scenarijus atrodys taip:

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

Apdorojus visus scenarijus belieka pridėti žurnalo konversiją. Mes naudojame etiketę after_script ir naudingumas plog-keitiklis:

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

Naudingumas plog-keitiklis yra atvirojo kodo projektas, naudojamas analizatoriaus klaidų ataskaitoms konvertuoti į įvairias formas, pvz., HTML. Išsamesnis programos aprašymas pateiktas poskyryje „Plog Converter Utility“ atitinkamą dokumentacijos skyrių.

Beje, jei norite patogiai dirbti su .json ataskaitomis vietoje iš IDE, siūlau mūsų prijungti pasižymėjo IDE Rider. Jo naudojimas išsamiau aprašytas atitinkamą dokumentą.

Patogumo dėlei čia jis yra .gitlab-ci.yml pilnai:

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

Kai viską pridėsite prie failo, spustelėkite Įsipareigoti pakeitimus. Norėdami įsitikinti, kad viskas teisinga, eikite į CI / CD -> Vamzdynai -> veikia. Atsidarys virtualios mašinos langas, kurio pabaigoje turėtų būti:

Pjūklas Darbas pavyko - Sėkmės, viskas gerai. Dabar galite išbandyti tai, ką padarėte.

Darbo pavyzdžiai

Norėdami gauti darbo pavyzdį, sukurkime paprastą projektą (in meistras), kuriame bus keli failai. Po to kitame filiale pakeisime tik vieną failą ir bandysime pateikti sujungimo užklausą.

Panagrinėkime du atvejus: kai pakeistame faile yra klaida, o kada jos nėra. Pirma, pavyzdys su klaida.

Tarkime, kad pagrindinėje šakoje yra failas Program.cs, kuriame klaidų nėra, tačiau kitoje šakoje kūrėjas pridėjo klaidingą kodą ir nori pateikti sujungimo užklausą. Kokią klaidą jis padarė, nėra taip svarbu, svarbiausia, kad ji būtų. Pavyzdžiui, operatorius pamiršo mesti (taip, taip negerai):

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

Pažvelkime į pavyzdžio su klaida analizės rezultatą. Taip pat norėdamas įsitikinti, kad buvo išanalizuotas tik vienas failas, pridėjau vėliavėlę -r į pvs-studio-dotnet paleidimo liniją:

Matome, kad analizatorius rado klaidą ir neleido sujungti šakų.

Patikrinkime pavyzdį be klaidos. Kodo taisymas:

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

Sujungti užklausų analizės rezultatai:

Kaip matome, klaidų nerasta, o užduotis įvykdyta sėkmingai, ką ir norėjome patikrinti.

išvada

Išnaikinti blogą kodą prieš sujungiant šakas yra labai patogu ir malonu. Taigi, jei naudojate CI / CD, pabandykite įdėti statinį analizatorių, kad patikrintumėte. Be to, tai daroma gana paprastai.

Ačiu už dėmesį.

Jei norite pasidalinti šiuo straipsniu su angliškai kalbančia auditorija, naudokite vertimo nuorodą: Nikolajus Mironovas. „GitLab“ sujungimo užklausų analizė naudojant PVS-Studio for C#.

Šaltinis: www.habr.com