🥇Analiza zahtev za spajanje v GitLabu z uporabo PVS-Studio za C#

Obožujete GitLab in sovražite hrošče? Želite izboljšati kakovost svoje izvorne kode? Potem ste prišli na pravo mesto. Danes vam bomo povedali, kako konfigurirati C# analizator PVS-Studio za preverjanje zahtev za spajanje. Samorogovo razpoloženje in prijetno branje vsem.

PVS-Studio je orodje za prepoznavanje napak in potencialnih ranljivosti v izvorni kodi programov, napisanih v C, C++, C# in Javi. Deluje na 64-bitnih sistemih v sistemih Windows, Linux in macOS. Lahko analizira kodo, zasnovano za 32-bitne, 64-bitne in vdelane platforme ARM.

Mimogrede, izdali smo PVS-Studio 7.08, v katerem smo naredili veliko stvari zanimivo. Na primer:

C# analizator za Linux in macOS;
vtičnik za Rider;
nov način preverjanja seznama datotek.

Način preverjanja seznama datotek

Prej je bilo za preverjanje določenih datotek potrebno analizatorju posredovati .xml s seznamom datotek. Ker pa to ni zelo priročno, smo dodali možnost prenosa .txt, kar zelo poenostavi življenje.

Če želite preveriti določene datoteke, morate določiti zastavico --sourceFiles (-f) in prenesite .txt s seznamom datotek. Videti je takole:

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

Če vas zanima nastavitev preverjanja potrditve ali zahtev za vlečenje, lahko to storite tudi s tem načinom. Razlika bo v pridobivanju seznama datotek za analizo in bo odvisna od sistemov, ki jih uporabljate.

Načelo preverjanja zahteve za združitev

Glavno bistvo preverjanja je zagotoviti, da težave, ki jih odkrije analizator med združevanjem, ne padejo v mojster podružnica. Prav tako ne želimo vsakič analizirati celotnega projekta. Še več, pri združevanju vej imamo seznam spremenjenih datotek. Zato predlagam, da dodate preverjanje zahteve za združitev.

Tako izgleda zahteva za združitev pred implementacijo statičnega analizatorja:

Se pravi vse napake, ki so bile v veji spremembe, se bo preselil v glavno vejo. Ker tega ne bi želeli, dodamo analizo in zdaj je diagram videti takole:

analiziranje spremembe2 in če ni napak, sprejmemo zahtevo za združitev, sicer jo zavrnemo.

Mimogrede, če vas zanima analiza odobritev in zahtev za vlečenje za C/C++, potem lahko preberete o tem tukaj.

GitLab

GitLab je odprtokodno spletno orodje življenjskega cikla DevOps, ki ponuja sistem za upravljanje repozitorija kode za Git z lastnim wikijem, sistemom za sledenje težavam, cevovodom CI/CD in drugimi funkcijami.

Preden začnete analizirati zahteve za združitev, se morate registrirati in naložiti svoj projekt. Če ne veste, kako to storiti, potem predlagam статью moj kolega.

Obvestilo. Spodaj opisani način postavitve okolja je eden od možnih. Cilj je prikazati korake za nastavitev okolja, potrebnega za analizo in zagon analizatorja. Morda bi bilo v vašem primeru bolj optimalno ločiti faze priprave okolja (dodajanje repozitorijev, namestitev analizatorja) in analize: na primer priprava Dockerjevih slik s potrebnim okoljem in njihova uporaba ali kakšen drug način.

Da bi bolje razumeli, kaj se bo zdaj zgodilo, predlagam, da si ogledate naslednji diagram:

Analizator za delovanje potrebuje .NET Core SDK 3, zato morate pred namestitvijo analizatorja dodati Microsoftove repozitorije, iz katerih bodo nameščene odvisnosti, potrebne za analizator. Dodajanje Microsoftovih repozitorijev za različne distribucije Linuxa opisano v ustreznem dokumentu.

Če želite namestiti PVS-Studio prek upravitelja paketov, boste morali dodati tudi repozitorije PVS-Studio. Dodajanje skladišč za različne distribucije je podrobneje opisano v ustrezni del dokumentacije.

Analizator za delovanje potrebuje licenčni ključ. Preizkusno licenco lahko dobite na stran za prenos analizatorja.

Obvestilo. Upoštevajte, da je za opisan način delovanja (analiza zahtev za združitev) potrebna licenca Enterprise. Če torej želite preizkusiti ta način delovanja, ne pozabite v polju »Sporočilo« označiti, da potrebujete licenco Enterprise.

Če pride do zahteve za združitev, moramo analizirati samo seznam spremenjenih datotek, sicer analiziramo vse datoteke. Po analizi moramo dnevnike pretvoriti v obliko, ki jo potrebujemo.

Zdaj, ko imate pred očmi algoritem dela, lahko nadaljujete s pisanjem scenarija. Če želite to narediti, morate spremeniti datoteko .gitlab-ci.yml ali, če ne obstaja, ga ustvarite. Če ga želite ustvariti, morate klikniti na ime vašega projekta -> Nastavite CI/CD.

Zdaj smo pripravljeni napisati scenarij. Najprej napišimo kodo, ki bo namestila analizator in vnesla licenco:

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

Ker morata biti namestitev in aktivacija izvedeni pred vsemi ostalimi skripti, uporabljamo posebno oznako pred_skript. Naj ta fragment malo razložim.

Priprava na namestitev analizatorja:

  - 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

Dodajanje skladišč in analizatorja 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

Aktivacija licence:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME - Uporabniško ime.

$PVS_KEY - ključ izdelka.

Obnovitev projektnih odvisnosti, kjer $CI_PROJECT_DIR – celotna pot do imenika projekta:

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

Za pravilno analizo mora biti projekt uspešno zgrajen in njegove odvisnosti je treba obnoviti (na primer prenesti potrebne pakete NuGet).

Spremenljivke okolja, ki vsebujejo informacije o licenci, lahko nastavite s klikom Nastavitev, in po - naprej CI/CD.

V oknu, ki se odpre, poiščite predmet Spremenljivke, kliknite na gumb na desni Razširi in dodajte spremenljivke. Rezultat bi moral izgledati takole:

Zdaj lahko nadaljujete z analizo. Najprej dodajmo skript za popolno analizo. Na zastavo -t zastavici podamo pot do rešitve -o napišite pot do datoteke, v katero bodo zapisani rezultati analize. Zanima nas tudi povratna koda. V tem primeru nas zanima, da se operacija ustavi, ko povratna koda vsebuje informacijo, da so bila med analizo izdana opozorila. Takole izgleda ta 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

Povratne kode delujejo po principu bitne maske. Na primer, če so bila kot rezultat analize izdana opozorila, bo povratna koda enaka 8. Če licenca poteče v enem mesecu, bo povratna koda enaka 4. Če so bile med analizo odkrite napake, in licenca poteče v enem mesecu, vrnitev kode, izpisani bosta obe vrednosti: seštejte številki in dobite končno povratno kodo - 8+4=12. Tako lahko s preverjanjem ustreznih bitov med analizo pridobimo informacije o različnih stanjih. Povratne kode so podrobneje opisane v razdelku "povratne kode pvs-studio-dotnet (Linux / macOS)" dokumenta "Preverjanje projektov Visual Studio / MSBuild / .NET Core iz ukazne vrstice s programom PVS-Studio".

V tem primeru nas zanimajo vse povratne kode, kjer se pojavi 8.

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

1 bomo prejeli, ko povratna koda vsebuje bit števila, ki nas zanima, sicer bomo prejeli 0.

Čas je, da dodamo analizo zahteve za združitev. Preden to naredimo, pripravimo prostor za scenarij. Potrebujemo, da se izvede le, ko pride do zahteve za združitev. Videti je takole:

merge:
  script:
  only:
  - merge_requests

Preidimo k samemu scenariju. Bil sem soočen z dejstvom, da virtualni stroj ne ve ničesar o izvor/gospodar. Pa ji malo pomagajmo:

  - git fetch origin

Zdaj dobimo razliko med vejami in shranimo rezultat txt mapa:

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

kjer je $CI_COMMIT_SHA – zgoščena vrednost zadnje objave.

Nato začnemo analizirati seznam datotek z uporabo zastavice -f. Vanj prenesemo prej prejeto datoteko .txt. No, po analogiji s celotno analizo pogledamo povratne kode:

  - 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

Celoten skript za preverjanje zahteve za združitev bo videti takole:

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

Vse, kar ostane, je dodati pretvorbo dnevnika, ko so vsi skripti obdelani. Uporabljamo oznako after_script in uporabnost plog-pretvornik:

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

Uporabnost plog-pretvornik je odprtokodni projekt, ki se uporablja za pretvorbo poročil o napakah razčlenjevalnika v različne oblike, kot je HTML. Podrobnejši opis pripomočka je naveden v pododdelku "Pripomoček Plog Converter Utility" ustrezni del dokumentacije.

Mimogrede, če želite udobno delati s poročili .json lokalno iz IDE, potem predlagam naše vtičnik za IDE Rider. Njegova uporaba je podrobneje opisana v ustrezni dokument.

Za udobje, tukaj je .gitlab-ci.yml v celoti:

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

Ko dodate vse v datoteko, kliknite na Uveljavi spremembe. Če želite preveriti, ali je vse pravilno, pojdite na CI / CD -> Cevovodi -> Tek. Odprlo se bo okno navideznega stroja, na koncu katerega bi moralo biti naslednje:

videl Delo je uspelo - uspeh, vse je v redu. Zdaj lahko preizkusite, kaj ste naredili.

Delovni primeri

Za primer dela ustvarimo preprost projekt (v mojster), ki bo vseboval več datotek. Nato bomo v drugi veji spremenili samo eno datoteko in poskusili narediti zahtevo za združitev.

Poglejmo si dva primera: ko spremenjena datoteka vsebuje napako in ko je ne. Najprej primer z napako.

Recimo, da je datoteka v glavni veji Program.cs, ki ne vsebuje napak, vendar je v drugi veji razvijalec dodal napačno kodo in želi narediti zahtevo za združitev. Kakšno napako je naredil, ni tako pomembno, glavno je, da obstaja. Na primer, operater je pozabil met (Da, tako narobe):

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

Poglejmo rezultat analize primera z napako. Da bi se prepričal, da je bila razčlenjena samo ena datoteka, sem dodal zastavico -r v zagonsko vrstico pvs-studio-dotnet:

Vidimo, da je analizator našel napako in ni dovolil združevanja vej.

Preverimo primer brez napake. Popravljanje kode:

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

Rezultati analize zahteve za združitev:

Kot lahko vidimo, ni bilo najdenih nobenih napak in izvedba naloge je bila uspešna, kar smo želeli preveriti.

Zaključek

Odstranjevanje slabe kode pred združevanjem vej je zelo priročno in prijetno. Torej, če uporabljate CI/CD, poskusite vdelati statični analizator za preverjanje. Poleg tega se to naredi precej preprosto.

Hvala za vašo pozornost.

Če želite ta članek deliti z angleško govorečim občinstvom, uporabite povezavo za prevod: Nikolay Mironov. Analiza zahtev za spajanje v GitLabu z uporabo PVS-Studio za C#.

Vir: www.habr.com

Analiza zahtev za spajanje v GitLabu z uporabo PVS-Studio za C#

Način preverjanja seznama datotek

Načelo preverjanja zahteve za združitev

GitLab

Delovni primeri

Zaključek

Dodaj komentar Prekliči odgovor