🥇Analiza zahtjeva za spajanje u GitLabu pomoću PVS-Studio za C#

Volite GitLab i mrzite bugove? Želite poboljšati kvalitetu svog izvornog koda? Onda ste došli na pravo mjesto. Danas ćemo vam reći kako konfigurirati PVS-Studio C# analizator za provjeru zahtjeva za spajanje. Neka jednorog raspoloženje i sretno čitanje svima.

PVS-Studio je alat za prepoznavanje pogrešaka i potencijalnih ranjivosti u izvornom kodu programa napisanih u C, C++, C# i Javi. Radi na 64-bitnim sustavima na Windows, Linux i macOS. Može analizirati kod dizajniran za 32-bitne, 64-bitne i ugrađene ARM platforme.

Usput, izdali smo PVS-Studio 7.08, u kojem smo napravili puno stvari zanimljiv, Na primjer:

C# analizator za Linux i macOS;
dodatak za Rider;
novi način provjere popisa datoteka.

Način provjere popisa datoteka

Ranije je za provjeru određenih datoteka bilo potrebno analizatoru proslijediti .xml s popisom datoteka. Ali budući da to nije baš zgodno, dodali smo mogućnost prijenosa .txt datoteke, što čini život vrlo jednostavnim.

Kako biste provjerili određene datoteke, morate navesti oznaku --sourceFiles (-f) i prenesite .txt s popisom datoteka. Ovako izgleda:

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

Ako ste zainteresirani za postavljanje provjere predaje ili zahtjeva za povlačenjem, to također možete učiniti pomoću ovog načina rada. Razlika će biti u dobivanju popisa datoteka za analizu i ovisit će o sustavima koje koristite.

Princip provjere zahtjeva za spajanje

Glavna bit provjere je osigurati da problemi koje detektira analizator tijekom spajanja ne padnu u majstor podružnica. Također ne želimo svaki put analizirati cijeli projekt. Štoviše, prilikom spajanja grana imamo popis promijenjenih datoteka. Stoga predlažem dodavanje provjere zahtjeva za spajanje.

Ovako izgleda zahtjev za spajanje prije implementacije statičkog analizatora:

Odnosno sve greške koje su bile u grani promjene, premjestit će se u glavnu granu. Pošto ovo ne bismo htjeli, dodali smo analizu i sada dijagram izgleda ovako:

Analiziramo promjene2 i, ako nema grešaka, prihvaćamo zahtjev za spajanje, u suprotnom ga odbijamo.

Usput, ako ste zainteresirani za analizu predaja i zahtjeva za povlačenjem za C/C++, onda možete pročitati o tome здесь.

GitLab

GitLab je DevOps alat za životni ciklus temeljen na webu otvorenog koda koji pruža sustav upravljanja spremištem koda za Git s vlastitim wikijem, sustavom za praćenje problema, CI/CD cjevovodom i drugim značajkama.

Prije nego počnete analizirati zahtjeve za spajanje, morate se registrirati i učitati svoj projekt. Ako ne znate kako to učiniti, predlažem članak moj kolega.

Primijetiti. Dolje opisani način postavljanja okruženja jedan je od mogućih. Cilj je prikazati korake za postavljanje okruženja potrebnog za analizu i pokretanje analizatora. Možda bi u vašem slučaju bilo optimalnije razdvojiti faze pripreme okruženja (dodavanje repozitorija, instaliranje analizatora) i analize: npr. pripremanje Docker slika s potrebnim okruženjem i njihovo korištenje ili neka druga metoda.

Da biste bolje razumjeli što će se sada dogoditi, predlažem da pogledate sljedeći dijagram:

Analizator zahtijeva .NET Core SDK 3 za rad, tako da prije instaliranja analizatora trebate dodati Microsoftove repozitorije iz kojih će se instalirati ovisnosti potrebne za analizator. Dodavanje Microsoftovih repozitorija za razne distribucije Linuxa opisano u odgovarajućem dokumentu.

Da biste instalirali PVS-Studio putem upravitelja paketima, morat ćete dodati i repozitorije PVS-Studio. Dodavanje repozitorija za različite distribucije detaljnije je opisano u relevantni odjeljak dokumentacije.

Analizatoru je za rad potreban licencni ključ. Probnu licencu možete dobiti na stranica za preuzimanje analizatora.

Primijetiti. Napominjemo da je za opisani način rada (analiza zahtjeva za spajanje) potrebna Enterprise licenca. Stoga, ako želite isprobati ovaj način rada, ne zaboravite u polju “Poruka” naznačiti da vam je potrebna Enterprise licenca.

Ako se pojavi zahtjev za spajanje, tada trebamo analizirati samo popis promijenjenih datoteka, inače analiziramo sve datoteke. Nakon analize moramo konvertirati zapisnike u format koji nam je potreban.

Sada, imajući algoritam rada pred očima, možete prijeći na pisanje scenarija. Da biste to učinili, morate promijeniti datoteku .gitlab-ci.yml ili, ako ne postoji, stvorite ga. Da biste ga izradili, morate kliknuti na naziv svog projekta -> Postavite CI/CD.

Sada smo spremni napisati scenarij. Prvo napišimo kod koji će instalirati analizator i unijeti licencu:

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

Budući da se instalacija i aktivacija moraju dogoditi prije svih ostalih skripti, koristimo posebnu oznaku prije_skripta. Dopustite mi da malo pojasnim ovaj fragment.

Priprema za instalaciju analizatora:

  - 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

Dodavanje PVS-Studio repozitorija i analizatora:

  - 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

Aktivacija licence:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME - Korisničko ime.

$PVS_KEY - Šifra proizvoda.

Oporavak ovisnosti projekta gdje $CI_PROJECT_DIR – puni put do direktorija projekta:

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

Za ispravnu analizu, projekt mora biti uspješno izgrađen, a njegove ovisnosti moraju biti vraćene (na primjer, moraju se preuzeti potrebni NuGet paketi).

Možete postaviti varijable okruženja koje sadrže informacije o licenci klikom Postavljanje, a nakon - na CI/CD.

U prozoru koji se otvori pronađite predmet Varijable, kliknite na gumb s desne strane Proširiti i dodajte varijable. Rezultat bi trebao izgledati ovako:

Sada možete prijeći na analizu. Prvo, dodajmo skriptu za potpunu analizu. Na zastavu -t put do rješenja prolazimo do zastave -o napišite put do datoteke u koju će biti upisani rezultati analize. Zanima nas i povratni kod. U ovom slučaju, zainteresirani smo za zaustavljanje operacije kada povratni kod sadrži informacije da su tijekom analize izdana upozorenja. Ovako izgleda ovaj 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

Povratni kodovi rade na principu bit maske. Na primjer, ako su kao rezultat analize izdana upozorenja, tada će povratni kod biti jednak 8. Ako licenca istekne unutar mjesec dana, tada će povratni kod biti jednak 4. Ako su tijekom analize otkrivene pogreške, i licenca istječe u roku od mjesec dana, povratni kod, bit će ispisane obje vrijednosti: zbrojite brojeve i dobit ćete konačni povratni kod - 8+4=12. Tako se provjerom odgovarajućih bitova tijekom analize mogu dobiti informacije o raznim stanjima. Povratni kodovi su detaljnije opisani u odjeljku "pvs-studio-dotnet (Linux / macOS) Povratni kodovi" dokumenta "Provjera Visual Studio / MSBuild / .NET Core projekata iz naredbenog retka pomoću PVS-Studio".

U ovom slučaju, zanimaju nas svi povratni kodovi gdje se pojavljuje 8.

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

Dobit ćemo 1 kada povratni kod sadrži bit broja koji nas zanima, inače ćemo dobiti 0.

Vrijeme je da dodate analizu zahtjeva za spajanje. Prije nego to učinimo, pripremimo mjesto za scenarij. Trebamo ga izvršiti samo kada se pojavi zahtjev za spajanje. Ovako izgleda:

merge:
  script:
  only:
  - merge_requests

Prijeđimo na sam scenarij. Suočio sam se s činjenicom da virtualni stroj ne zna ništa o tome porijeklo/gospodar. Pa hajde da joj malo pomognemo:

  - git fetch origin

Sada dobivamo razliku između grana i spremamo rezultat txt datoteka:

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

gdje $CI_COMMIT_SHA – hash posljednjeg urezivanja.

Zatim počinjemo analizirati popis datoteka pomoću oznake -f. Na njega prenosimo prethodno primljenu .txt datoteku. Pa, po analogiji s potpunom analizom, gledamo povratne kodove:

  - 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

Kompletna skripta za provjeru zahtjeva za spajanje izgledat će ovako:

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

Sve što preostaje je dodati konverziju dnevnika nakon što su sve skripte obrađene. Koristimo oznaku nakon_skripte i korisnosti plog-pretvarač:

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

Korisnost plog-pretvarač je projekt otvorenog koda koji se koristi za pretvaranje izvješća o pogreškama parsera u različite oblike, kao što je HTML. Detaljniji opis uslužnog programa dat je u pododjeljku "Plog Converter Utility" relevantni odjeljak dokumentacije.

Usput, ako želite praktično raditi s .json izvješćima lokalno iz IDE-a, predlažem naš plugin za IDE Rider. Njegova uporaba je detaljnije opisana u relevantni dokument.

Radi praktičnosti, evo ga .gitlab-ci.yml u cijelosti:

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

Nakon što ste sve dodali u datoteku, kliknite na Obavijesti promjene. Kako biste vidjeli da je sve ispravno, idite na CI / CD -> Cjevovodi -> Trčanje. Otvorit će se prozor virtualnog stroja na čijem bi kraju trebalo biti sljedeće:

pila Posao je uspio - uspjeh, sve je u redu. Sada možete testirati što ste učinili.

Primjeri rada

Za primjer rada, stvorimo jednostavan projekt (in majstor) koji će sadržavati nekoliko datoteka. Nakon toga ćemo u drugoj grani promijeniti samo jednu datoteku i pokušati napraviti zahtjev za spajanje.

Razmotrimo dva slučaja: kada modificirana datoteka sadrži grešku i kada je nema. Prvo, primjer s greškom.

Recimo da postoji datoteka u glavnoj grani Program.cs, koji ne sadrži pogreške, ali u drugoj grani programer je dodao pogrešan kod i želi podnijeti zahtjev za spajanje. Kakvu je grešku napravio nije toliko važno, glavno je da postoji. Na primjer, operater je zaboravio baciti (Da, tako krivo):

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

Pogledajmo rezultat analize primjera s greškom. Također kako bih bio siguran da je samo jedna datoteka raščlanjena, dodao sam oznaku -r na liniju pokretanja pvs-studio-dotnet:

Vidimo da je analizator pronašao grešku i nije dopustio spajanje grana.

Provjerimo primjer bez greške. Ispravljanje koda:

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

Rezultati analize zahtjeva za spajanje:

Kao što vidimo, greške nisu pronađene, a izvršenje zadatka je bilo uspješno, što smo i htjeli provjeriti.

Zaključak

Uklanjanje lošeg koda prije spajanja grana vrlo je zgodno i ugodno. Dakle, ako koristite CI/CD, pokušajte ugraditi statički analizator za provjeru. Štoviše, to se radi vrlo jednostavno.

Hvala na pozornosti.

Ako želite podijeliti ovaj članak s publikom koja govori engleski, upotrijebite vezu za prijevod: Nikolay Mironov. Analiza zahtjeva za spajanje u GitLabu pomoću PVS-Studio za C#.

Izvor: www.habr.com

Analiza zahtjeva za spajanje u GitLabu pomoću PVS-Studio za C#

Način provjere popisa datoteka

Princip provjere zahtjeva za spajanje

GitLab

Primjeri rada

Zaključak

Dodajte komentar Odustani odgovor