Egyesítési kérelmek elemzése a GitLabban a PVS-Studio for C# segítségével

Szereted a GitLabot és utálod a hibákat? Szeretné javítani forráskódja minőségén? Akkor jó helyre jött. Ma elmondjuk, hogyan konfigurálhatja a PVS-Studio C# elemzőt az egyesítési kérelmek ellenőrzésére. Egyszarvú hangulatot és jó olvasást mindenkinek.

PVS-Stúdió egy eszköz a C, C++, C# és Java nyelven írt programok forráskódjának hibáinak és lehetséges sebezhetőségeinek azonosítására. 64 bites rendszereken működik Windows, Linux és macOS rendszeren. Képes elemezni a 32 bites, 64 bites és beágyazott ARM platformokhoz tervezett kódot.

Egyébként kiadtuk a PVS-Studio 7.08-at, amiben sok mindent csináltunk érdekes. Például:

• C# elemző Linux és macOS számára;
• plugin a Riderhez;
• új fájllista ellenőrzési mód.

Fájllista ellenőrzési mód

Korábban bizonyos fájlok ellenőrzéséhez egy .xml fájlt kellett átadni a fájlok listájával az elemzőnek. De mivel ez nem túl kényelmes, hozzáadtuk a .txt átvitelének lehetőségét, ami nagyon leegyszerűsíti az életet.

Adott fájlok ellenőrzéséhez meg kell adnia a zászlót --forrás fájlok (-f), és vigye át a .txt fájlt a fájlok listájával együtt. Ez így néz ki:

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

Ha érdekel a véglegesítési ellenőrzés vagy lehívási kérelmek beállítása, ezt megteheti ezzel a móddal is. A különbség abban lesz, hogy megkapja az elemezni kívánt fájlok listáját, és attól függ, hogy milyen rendszereket használ.

Az összevonási kérelem ellenőrzésének elve

Az ellenőrzés lényege annak biztosítása, hogy az analizátor által észlelt problémák ne kerüljenek az egyesítő kódba. mester ág. Nem akarjuk minden alkalommal elemezni a teljes projektet. Sőt, az ágak egyesítésekor a megváltozott fájlok listáját kapjuk. Ezért azt javaslom, hogy adjon hozzá egy összevonási kérelem ellenőrzést.

Így néz ki egy összevonási kérelem a statikus elemző megvalósítása előtt:

Vagyis az összes hiba, ami az ágban volt változások, átkerül a fő ágra. Mivel ezt nem szeretnénk, elemzést adunk hozzá, és most a diagram így néz ki:

Elemezzük változások2 és ha nincs hiba, elfogadjuk az összevonási kérelmet, ellenkező esetben elutasítjuk.

Egyébként, ha érdekel a C/C++ commit és pull kérések elemzése, akkor olvass róla itt.

GitLab

GitLab egy nyílt forráskódú web-alapú DevOps életciklus-eszköz, amely kódtár-kezelő rendszert biztosít a Git számára saját wikivel, problémakövető rendszerrel, CI/CD-folyamattal és egyéb szolgáltatásokkal.

Mielőtt elkezdené az egyesítési kérelmek elemzését, regisztrálnia kell, és fel kell töltenie projektjét. Ha nem tudja, hogyan kell ezt csinálni, akkor azt javaslom статью a kollégám.

Megjegyzés. Az alábbiakban ismertetett környezet kialakítási módszer a lehetségesek egyike. A cél az elemzéshez és az analizátor elindításához szükséges környezet beállításának lépései bemutatása. Talán az Ön esetében optimálisabb lenne a környezet-előkészítés (repozitóriumok hozzáadása, elemző telepítése) és az elemzés szakaszait különválasztani: például Docker képek elkészítése a szükséges környezettel és felhasználásuk, vagy más módszer.

Hogy jobban megértsük, mi fog most történni, javaslom, hogy nézze meg a következő diagramot:

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 adni azokat a Microsoft tárolókat, amelyekből az elemzőhöz szükséges függőségek telepítésre kerülnek. Microsoft-tárolók hozzáadása a különböző Linux-disztribúciókhoz a megfelelő dokumentumban leírtak szerint.

A PVS-Studio csomagkezelőn keresztüli telepítéséhez hozzá kell adnia a PVS-Studio tárolókat is. A különböző disztribúciókhoz tartozó tárhelyek hozzáadását részletesebben a következő tartalmazza: a dokumentáció megfelelő részét.

Az analizátor működéséhez licenckulcs szükséges. Próbaengedélyt a címen szerezhet be elemző letöltési oldal.

Megjegyzés. Felhívjuk figyelmét, hogy a leírt működési mód (egyesítési kérelmek elemzése) vállalati licencet igényel. Ezért, ha ki akarja próbálni ezt a működési módot, ne felejtse el az „Üzenet” mezőben jelezni, hogy vállalati licencre van szüksége.

Ha összevonási kérés történik, akkor csak a megváltozott fájlok listáját kell elemeznünk, ellenkező esetben az összes fájlt elemezzük. Az elemzés után a naplókat a szükséges formátumba kell konvertálnunk.

Most, amikor a munka algoritmusa a szeme előtt van, továbbléphet a forgatókönyv megírására. Ehhez módosítania kell a fájlt .gitlab-ci.yml vagy ha nem létezik, hozza létre. Létrehozásához kattintson a projekt nevére -> Állítsa be a CI/CD-t.

Most készen állunk a forgatókönyv megírására. Először írjuk meg a kódot, amely telepíti az elemzőt, és adja meg 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ésnek és az aktiválásnak minden más szkript előtt kell megtörténnie, speciális címkét használunk előtt_szkript. Hadd magyarázzam el egy kicsit ezt a töredéket.

Az analizátor 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

PVS-Studio adattárak és elemző 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

Licenc aktiválása:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME - Felhasználónév.

$PVS_KEY - termékkulcs.

Projektfüggőségek helyreállítása hol $CI_PROJECT_DIR – a projektkönyvtár teljes elérési útja:

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

A helyes elemzéshez a projektet sikeresen fel kell építeni, és vissza kell állítani a függőségeit (például le kell tölteni a szükséges NuGet csomagokat).

A licencinformációkat tartalmazó környezeti változókat a gombra kattintva állíthatja be Beállítás, és utána - be CI/CD.

A megnyíló ablakban keresse meg az elemet Változók, kattintson a jobb oldalon található gombra Bontsa és adjunk hozzá változókat. Az eredménynek így kell kinéznie:

Most továbbléphet az elemzésre. Először is adjunk hozzá egy szkriptet a teljes elemzéshez. A zászlóhoz -t a megoldáshoz vezető utat átadjuk a zászlónak -o írja be annak a fájlnak az elérési útját, amelybe az elemzési eredményeket írjuk. A visszaküldési kód is érdekel minket. Ebben az esetben arra vagyunk kíváncsiak, hogy a művelet leálljon, amikor a visszatérési kód olyan információt tartalmaz, hogy az elemzés során figyelmeztetéseket adtak ki. Így néz ki ez a töredék:

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 a bitmaszk elvén működnek. Például, ha az elemzés eredményeként figyelmeztetéseket adtak ki, akkor a visszaküldési kód 8 lesz. Ha az engedély egy hónapon belül lejár, akkor a visszaküldési kód 4 lesz. Ha az elemzés során hibákat észleltek, és a licenc egy hónapon belül lejár, a kód visszatér, mindkét érték kiírásra kerül: ö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 az elemzés során különböző állapotokról nyerhetünk információkat. A visszaküldési kódok részletesebb leírása a dokumentum "pvs-studio-dotnet (Linux / macOS) Return Codes" szakaszában található.Visual Studio / MSBuild / .NET Core projektek ellenőrzése a parancssorból a PVS-Studio segítségével".

Ebben az esetben minden olyan visszatérési kódra vagyunk kíváncsiak, ahol a 8 jelenik meg.

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

1-et akkor kapunk, ha a visszatérési kód tartalmazza a minket érdeklő szám bitjét, ellenkező esetben 0-t kapunk.

Ideje hozzáadni az egyesítési kérelem elemzését. Mielőtt ezt megtennénk, készítsünk egy helyet a forgatókönyvnek. Csak akkor kell végrehajtanunk, ha összevonási kérés történik. Ez így néz ki:

merge:
  script:
  only:
  - merge_requests

Térjünk át magára a forgatókönyvre. Szembesültem azzal a ténnyel, hogy a virtuális gép nem tud róla semmit származás/mester. Szóval segítsünk neki egy kicsit:

  - git fetch origin

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

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

ahol $CI_COMMIT_SHA – az utolsó commit hash-je.

Ezután elkezdjük elemezni a fájlok listáját a zászló segítségével -f. A korábban kapott .txt fájlt átvisszük rá. Nos, a teljes elemzés analógiájára nézzük 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

Az egyesítési kérelem ellenőrzésére szolgáló 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

Nincs más hátra, mint a naplókonverzió hozzáadása az összes szkript feldolgozása után. Használjuk a címkét after_script és a hasznosság plog-konverter:

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

Hasznosság plog-konverter egy nyílt forráskódú projekt, amely az elemző hibajelentéseinek különféle formákra, például HTML-re konvertálására szolgál. A segédprogram részletesebb leírása a "Plog Converter Utility" alszakaszban található. a dokumentáció megfelelő részét.

Egyébként, ha kényelmesen szeretne dolgozni a .json jelentésekkel helyben az IDE-ről, akkor azt javaslom, bővítmény az IDE Rider számára. Használatát részletesebben a vonatkozó dokumentumot.

A kényelem kedvéért itt van .gitlab-ci.yml teljesen:

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

Miután mindent hozzáadott a fájlhoz, kattintson a gombra Végezze el a változtatásokat. Ha látni szeretné, hogy minden rendben van-e, menjen a címre CI / CD -> Csővezetékek -> futás. Megnyílik egy virtuális gép ablak, amelynek végén a következőnek kell lennie:

fűrész Jobnak sikerült - siker, minden rendben. Most tesztelheti, mit tett.

Munka példák

Példaként a munkára hozzunk létre egy egyszerű projektet (in mester), amely több fájlt tartalmaz majd. Ezt követően egy másik ágban csak egy fájlt módosítunk, és megpróbálunk összevonási kérelmet benyújtani.

Vegyünk két esetet: amikor a módosított fájl hibát tartalmaz, és mikor nem. Először is egy példa hibával.

Tegyük fel, hogy van egy fájl a master ágban Program.cs, amely nem tartalmaz hibákat, de egy másik ágban a fejlesztő hibás kódot adott hozzá, és összevonási kérelmet szeretne tenni. Hogy milyen hibát követett el, az nem annyira fontos, a lényeg, hogy létezik. Például az operátor elfelejtette dobás (Igen, nagyon rossz):

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

Nézzük meg egy hibás példa elemzésének eredményét. Annak érdekében, hogy megbizonyosodjon arról, hogy csak egy fájl került elemzésre, hozzáadtam a zászlót -r a pvs-studio-dotnet indítósorához:

Látjuk, hogy az analizátor hibát talált, és nem engedélyezte az ágak összevonását.

Vizsgáljuk meg a példát hiba nélkül. A kód javítása:

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

Egyesítési kérelem elemzési eredményei:

Mint látjuk, hibát nem találtunk, a feladat végrehajtása sikeres volt, ezt szerettük volna ellenőrizni.

Következtetés

A rossz kód kigyomlálása az ágak összevonása előtt nagyon kényelmes és kellemes. Tehát ha CI/CD-t használ, próbáljon meg egy statikus elemzőt beágyazni az ellenőrzéshez. Ráadásul ez egészen egyszerűen megtörténik.

Köszönöm a figyelmet.

Ha meg szeretné osztani ezt a cikket egy angolul beszélő közönséggel, kérjük, használja a fordítási linket: Nikolay Mironov. Egyesítési kérelmek elemzése a GitLabban a PVS-Studio for C# segítségével.

Forrás: will.com