🥇Merge requestek elemzése a GitLabban a PVS-Studio segítségével C#-hoz

Szereted a GitLab-t, de nem szereted a hibákat? Szeretnéd javítani a forráskód minőségét? Akkor jó helyen jársz. Ma elmondjuk, hogyan állíthatod be a C# PVS-Studio analizátort a merge requestek ellenőrzésére. Mindannyiunknak varázslatos hangulat és szép olvasást kívánunk.

PVS-Studio — ez egy eszköz a programok forráskódjában lévő hibák és potenciális sebezhetőségek felderítésére, amelyek C, C++, C# és Java nyelveken íródtak. 64-bites rendszereken működik Windows, Linux és macOS alatt. Képes elemezni a 32-bites, 64-bites és beágyazott ARM platformokra szánt kódot.

Amúgy megjelent a PVS-Studio 7.08, amelyben sok újítást hoztunk. érdekes dolgok. Például:

C# analizátor Linuxra és macOS-re;
plugin Riderhez;
új fájl lista ellenőrzési módszer.

Fájlok ellenőrzési mód

Korábban, ha meghatározott fájlokat szeretett volna ellenőrizni, a analizátornak .xml fájlt kellett átadni a fájlok listájával. De mivel ez nem volt túl kényelmes, lehetőséget adtunk .txt fájlok átadására, ami nagyban megkönnyíti az életet.

Ahhoz, hogy bizonyos fájlokat ellenőrizhessünk, meg kell adni a következő zászlót: —sourceFiles (-f) és át kell adni egy .txt fájlt a fájlok listájával. Ez így néz ki:

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

Ha érdekel a commitok vagy pull requestek ellenőrzése, ezt is megteheted e mód használatával. A különbség a fájlok lista megszerzésében rejlik az elemzéshez, és attól függ, hogy milyen rendszereket használsz.

A merge request ellenőrzésének alapelve

Az ellenőrzés lényege, hogy az analizátor által felfedezett problémák ne kerüljenek be a master ágba. Ezen kívül nem szeretnénk minden alkalommal az egész projektet elemezni. Ráadásul, amikor ágakat olvasztunk össze, van egy lista a módosított fájlokról. Ezért javaslom a merge requestek ellenőrzésének hozzáadását.

Így néz ki egy merge request a statikus analizátor bevezetése előtt:

Tehát minden hiba, ami az ágon volt, változások, átkerül a master ágba. Mivel ezt nem szeretnénk, bevezetjük az elemzést, és most a séma a következőképpen néz ki:

Ellenőrizzük changes2 és ha nincsenek hibák, elfogadjuk a merge requestet, ellenkező esetben elutasítjuk azt.

Amúgy, ha érdekel a commitok és pull requestek elemzése C/C++ számára, olvashatsz erről itt.

GitLab

GitLab — egy nyílt forráskódú DevOps életciklus webes eszköz, amely a Git kódkezelő rendszerét képviseli saját wikipédiával, hibakövető rendszerrel, CI/CD folyamattal és egyéb funkciókkal.

Mielőtt hozzákezdenénk a merge request-ek elemzésének végrehajtásához, regisztrálnia kell és feltöltenie a projektjét. Ha nem tudja, hogyan kell ezt megtenni, javaslom, cikket a kollégám.

Megjegyzés. Az alábbiakban leírt környezetbeállítási módszer az egyik lehetséges. A cél az, hogy bemutassuk az elemzéshez szükséges környezet beállításának lépéseit és az elemző elindítását. Lehet, hogy az Ön esetében optimálisabb lesz a környezet előkészítési lépéseinek (tárolók hozzáadása, az elemző telepítése) és az elemzés szétválasztása: például a szükséges környezettel rendelkező Docker képek előkészítése és azok használata, vagy valami más módszer.

Annak érdekében, hogy érthetőbb legyen, mi fog történni, javaslom, hogy nézze meg az alábbi sémát:

Az elemző működéséhez .NET Core SDK 3 szükséges, ezért az elemző telepítése előtt hozzá kell adnia a Microsoft tárolókat, ahonnan az elemzőhez szükséges függőségeket telepítik. A Microsoft tárolók hozzáadása a különböző Linux disztribúciókhoz a megfelelő dokumentumban van leírva..

A PVS-Studio telepítéséhez a csomagkezelőn keresztül is szükséges hozzáadni a PVS-Studio tárolókat. A tárolók hozzáadásának folyamata a különböző disztribúciókhoz részletesen van leírva a dokumentáció megfelelő szakaszában..

Az elemző működéséhez licenszkulcsra van szükség. Próbaverziót kérhet a elemző letöltési oldalán..

Megjegyzés. Ne feledje, hogy az itt leírt működési módhoz (merge request-ek elemzése) Enterprise licenc szükséges. Tehát, ha ki szeretné próbálni ezt a működési módot, a "Üzenet" mezőben ne felejtse el jelezni, hogy pontosan Enterprise licencet szeretne.

Ha merge request történik, csak a módosított fájlok listáját kell elemeznünk, ellenkező esetben minden fájlt elemezünk. Az elemzés után a naplókat a számunkra szükséges formátumra kell konvertálnunk.

Most, hogy előttünk van a munkafolyamat algoritmusa, elkezdhetjük a szkript írását. Ehhez módosítani kell a .gitlab-ci.yml fájlt, vagy ha az nem létezik, létre kell hozni. Az új fájl létrehozásához kattintson a projekt neve -> CI/CD beállítása.

Most már készen állunk a szkript írására. Először írjunk egy kódot, amely telepíti az elemzőt és beírja a licencet:

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

Mivel a telepítést és aktiválást minden más szkript előtt kell végrehajtani, külön címkét használunk before_cache. Egy kicsit kifejtem ezt a szakaszt.

A PVS-Studio elemző telepítésének előkészítése:

  - 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

A PVS-Studio és az elemző tárolók hozzáadása:

  - 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

A licenc aktiválása:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME — felhasználónév.

$PVS_KEY — termékkulcs.

A projekt függőségeinek helyreállítása, ahol $CI_PROJECT_DIR – a projekt mappájának teljes útvonala:

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

A helyes elemzés érdekében a projektnek sikeresen kell összeállnia, és a függőségeket helyre kell állítani (például a szükséges NuGet csomagoknak le kell tölteniük).

A licencinformációkat tartalmazó környezeti változókat az alábbi gombra kattintva állíthatjuk be Beállítás, majd ezt követően kattintsunk a Gitlab CI.

Az megnyíló ablakban keressük meg a Változókpontot, jobbra kattintsunk a Kibővít gombra, és adjuk hozzá a változókat. Ennek eredményeként a következőnek kell lennie:

Most már a végrehajtásra léphetünk. Először adjunk hozzá egy szkriptet a teljes elemzéshez. A flagbe - folyamatosan „pingelni” (a leállításhoz nyomjuk meg a Ctrl+C kombinációt) adjuk meg a solution útvonalát, a másik flagbe -o írjuk be a fájl útvonalát, amelybe az elemzés eredményei lesznek rögzítve. A visszatérési kód is érdekel minket. Ebben az esetben fontos, hogy a munka leálljon, amikor a visszatérési kód információt ad arról, hogy a szkennelés során figyelmeztetéseket adtak ki. Így néz ki ez a szakasz:

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

A visszatérési kódok bitmaszk elvén működnek. Például, ha az elemzés során figyelmeztetések merültek fel, a visszatérési kód 8 lesz. Ha a licence egy hónapon belül lejár, a visszatérési kód 4 lesz. Ha pedig az elemzés során hibákat találtunk, és a licence egy hónapon belül lejár, a visszatérési kódban mindkét érték szerepel: összeadjuk a számokat, és megkapjuk a végső visszatérési kódot — 8+4=12. Így a megfelelő bitek ellenőrzésével információt nyerhetünk a különböző állapotokról az elemzés során. A visszatérési kódokat részletesen a "PVS-Studio visszatérési kódok (Linux / macOS)" dokumentumban ismertetjük.A Visual Studio / MSBuild / .NET Core projektek parancssori ellenőrzése PVS-Studio segítségével.".

Ebben az esetben minden olyan visszatérési kód érdekel minket, amelyben a 8 szerepel.

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

1-et kapunk, amikor a visszatérési kód tartalmazza a számunkra érdekes bitet, különben 0-t kapunk.

Eljött az idő, hogy hozzáadjuk a merge kérelem elemzését. Mielőtt ezt megtennénk, készítsük el a helyet a szkript számára. Csak akkor kell futnia, amikor merge kérelem történik. Ez így néz ki:

merge:
  script:
  only:
  - merge_requests

Lépjünk a szkriptre. Szembesültem azzal, hogy a virtuális gép semmit sem tud az origin/master. Ezért egy kicsit segítünk neki:

  - git fetch origin

Most megkapjuk az ágak közötti különbséget, és elmentjük az eredményt a txt fájlhoz:

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

Ahol $CI_COMMIT_SHA – az utolsó commit hash.

Ezután elindítjuk a fájlok listájának elemzését a -fflag segítségével. Ezt továbbítjuk a korábban kapott .txt fájlhoz. A teljes elemzéshez hasonlóan nézzük meg a visszatérési kódokat:

  - 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

A merge kérés ellenőrzéséhez szükséges teljes szkript így fog kinézni:

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

Csak annyit kell hozzáadnunk, hogy a log konvertálása a szkriptek futtatása után történjen. Használjuk a címkét ▍Tesztelés és az utilitást. plog-converter:

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

Eszköz plog-converter — egy open source projekt, amely az elemző hibajelentésének különböző formákba, például HTML-be való átkonvertálására szolgál. A segédprogram részletes leírását a "Plog Converter segédprogram" alcím tartalmazza. a dokumentáció megfelelő szakaszát.

Egyébként, ha kényelmesen szeretnéd kezelni a .json jelentést helyben az IDE-ből, javaslom a mi bővítmény Rider IDE-hez. A használata részletesen a megfelelő dokumentumban található..

Kényelmesen itt van .gitlab-ci.yml teljes egészében:

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

Amint mindent hozzáadtál a fájlhoz, kattints a Commit changes. Annak érdekében, hogy megnézd, minden rendben van-e, menj a CI/CD -> Pipelines -> Futásban. Megnyílik egy virtuális gép ablaka, amelynek végén a következőt kell látnod:

Láttuk Job succeeded – siker, minden kiváló. Most már tesztelhetjük, amit létrehoztunk.

Működési példák

Például készítsünk egy egyszerű projektet (a master) néhány fájllal. Ezután egy másik ágban módosítsunk csak egy fájlt, és próbáljunk merge request-et létrehozni.

Két esetet fogunk megvizsgálni: amikor a módosított fájl hibát tartalmaz, és amikor nem. Először az a példa, amely tartalmaz hibát.

Tegyük fel, hogy a master ágon van a Program.cs, amely nem tartalmaz hibát, míg egy másik ágban a fejlesztő hibás kódot adott hozzá, és merge request-et szeretne létrehozni. Milyen hibát is vétett – nem annyira fontos, a lényeg, hogy van. Például elfelejtette a parancsot, throw (igen, így hibáznak):

void MyAwesomeMethod(String name)
{
  if (name == null)
    new ArgumentNullException(....);
  // csinálj valamit
  ....
}

Nézzük meg a hibás példa elemzésének eredményét. Annak érdekében, hogy megbizonyosodjak róla, hogy csak egy fájl került elemzésre, hozzáadtam a flag-et -r a pvs-studio-dotnet indítóparancsához:

Látjuk, hogy az elemző hibát talált, és nem tette lehetővé az ágak egyesítését.

Nézzük meg a hiba nélküli példát. Javítsuk a kódot:

void MyAwesomeMethod(String name)
{
  if (name == null)
    throw new ArgumentNullException(....);
  // csinálj valamit
  ....
}

A merge request elemzésének eredményei:

Ahogy látjuk, hibákat nem találtak, és a feladat végrehajtása sikeresen megtörtént, amit szerettünk volna ellenőrizni.

Zárás

Jó a rossz kód szűrése az ágak egyesítése előtt — ez nagyon kényelmes és kellemes. Ezért, ha CI/CD-t használsz, próbáld meg beépíteni a statikus elemzőt a teszteléshez. Ráadásul ezt elég egyszerűen meg lehet tenni.

Köszönöm a figyelmet.

Ha meg szeretnéd osztani ezt a cikket az angol nyelvű közönséggel, kérlek, használd a fordítás linkjét: Nikolay Mironov. Merge requestek elemzése a GitLab-ban a PVS-Studio segítségével C#-hoz.

Forrás: habr.com

Merge kérések elemzése a GitLab-ban a PVS-Studio segítségével C#-hoz

Fájlok ellenőrzési mód

A merge request ellenőrzésének alapelve

GitLab

Működési példák

Zárás