Analys av sammanslagningsförfrågningar i GitLab med PVS-Studio för C#

Analys av sammanslagningsförfrågningar i GitLab med PVS-Studio för C#
Älskar GitLab och hatar buggar? Vill du förbättra kvaliteten på din källkod? Då har du kommit rätt. Idag kommer vi att berätta hur du konfigurerar PVS-Studio C#-analysatorn för att kontrollera sammanslagningsförfrågningar. Ha ett enhörningshumör och trevlig läsning till alla.

PVS-studio är ett verktyg för att identifiera fel och potentiella sårbarheter i källkoden för program skrivna i C, C++, C# och Java. Fungerar på 64-bitars system på Windows, Linux och macOS. Kan analysera kod designad för 32-bitars, 64-bitars och inbäddade ARM-plattformar.

Förresten, vi släppte PVS-Studio 7.08, där vi gjorde många saker intressant. Till exempel:

  • C#-analysator för Linux och macOS;
  • plugin för Rider;
  • ny fillista kontrollläge.

Kontrollläge för fillistan

Tidigare, för att kontrollera vissa filer, var det nödvändigt att skicka en .xml med en lista över filer till analysatorn. Men eftersom detta inte är särskilt bekvämt har vi lagt till möjligheten att överföra .txt, vilket gör livet väldigt enkelt.

För att kontrollera specifika filer måste du ange flaggan --sourceFiles (-f) och överför .txt med en lista över filer. Det ser ut så här:

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

Om du är intresserad av att ställa in commit-kontroll eller pull-förfrågningar kan du också göra det med det här läget. Skillnaden kommer att vara att få en lista över filer att analysera och beror på vilka system du använder.

Principen för att kontrollera en sammanslagningsförfrågan

Huvudessensen av kontrollen är att säkerställa att problem som upptäcks av analysatorn under sammanslagning inte faller in i Master gren. Vi vill inte heller analysera hela projektet varje gång. Dessutom, när vi slår samman grenar, har vi en lista över ändrade filer. Därför föreslår jag att du lägger till en kontroll av sammanslagningsförfrågan.

Så här ser en sammanslagningsförfrågan ut innan en statisk analysator implementeras:

Analys av sammanslagningsförfrågningar i GitLab med PVS-Studio för C#
Det vill säga alla fel som fanns i grenen förändringar, kommer att flyttas till huvudgrenen. Eftersom vi inte vill ha detta lägger vi till analys och nu ser diagrammet ut så här:

Analys av sammanslagningsförfrågningar i GitLab med PVS-Studio för C#
Analyserar ändringar 2 och om det inte finns några fel accepterar vi sammanslagningsbegäran, annars avvisar vi den.

Förresten, om du är intresserad av att analysera commits och pull-förfrågningar för C/C++, då kan du läsa om det här.

GitLab

GitLab är ett webbaserat DevOps-livscykelverktyg med öppen källkod som tillhandahåller ett kodlagerhanteringssystem för Git med sin egen wiki, problemspårningssystem, CI/CD-pipeline och andra funktioner.

Innan du börjar analysera sammanslagningsförfrågningar måste du registrera dig och ladda upp ditt projekt. Om du inte vet hur man gör detta, då föreslår jag Artikel min kollega.

Notera. Metoden för att ställa in miljön som beskrivs nedan är en av de möjliga. Målet är att visa stegen för att ställa in den miljö som krävs för analys och lansering av analysatorn. Kanske i ditt fall skulle det vara mer optimalt att separera stadierna av miljöförberedelse (lägga till förråd, installera en analysator) och analys: till exempel förbereda Docker-bilder med den nödvändiga miljön och använda dem, eller någon annan metod.

För att bättre förstå vad som kommer att hända nu föreslår jag att du tittar på följande diagram:

Analys av sammanslagningsförfrågningar i GitLab med PVS-Studio för C#
Analysatorn kräver .NET Core SDK 3 för att fungera, så innan du installerar analysatorn måste du lägga till Microsoft-repositories från vilka de beroenden som krävs för analysatorn kommer att installeras. Lägga till Microsoft-arkiv för olika Linux-distributioner beskrivs i motsvarande dokument.

För att installera PVS-Studio genom pakethanteraren måste du också lägga till PVS-Studio-förråden. Att lägga till repositories för olika distributioner beskrivs mer i detalj i relevant avsnitt i dokumentationen.

Analysatorn kräver en licensnyckel för att fungera. Du kan få en provlicens på sida för nedladdning av analysator.

Notera. Observera att det beskrivna driftsättet (analys av sammanslagningsförfrågningar) kräver en Enterprise-licens. Därför, om du vill prova detta driftsätt, glöm inte att ange i fältet "Meddelande" att du behöver en Enterprise-licens.

Om en sammanfogningsförfrågan inträffar behöver vi bara analysera listan med ändrade filer, annars analyserar vi alla filer. Efter analys måste vi konvertera loggarna till det format vi behöver.

Nu, med algoritmen för arbete framför dina ögon, kan du gå vidare till att skriva ett manus. För att göra detta måste du ändra filen .gitlab-ci.yml eller, om det inte finns, skapa det. För att skapa det måste du klicka på namnet på ditt projekt -> Ställ in CI/CD.

Analys av sammanslagningsförfrågningar i GitLab med PVS-Studio för C#
Nu är vi redo att skriva manuset. Låt oss först skriva koden som ska installera analysatorn och ange licensen:

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

Eftersom installation och aktivering måste ske före alla andra skript använder vi en speciell etikett före_script. Låt mig förklara detta fragment lite.

Förbereder installation av analysatorn:

  - 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

Lägga till PVS-Studio-förråd och analysator:

  - 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

Licensaktivering:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME - Användarnamn.

$PVS_KEY - produktnyckel.

Återställa projektberoenden var $CI_PROJECT_DIR – fullständig sökväg till projektkatalogen:

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

För korrekt analys måste projektet byggas framgångsrikt och dess beroenden måste återställas (till exempel måste de nödvändiga NuGet-paketen laddas ner).

Du kan ställa in miljövariabler som innehåller licensinformation genom att klicka Att lägga plattor, och efteråt CI/CD.

Analys av sammanslagningsförfrågningar i GitLab med PVS-Studio för C#
Hitta objektet i fönstret som öppnas variabler, klicka på knappen till höger Bygga ut och lägg till variabler. Resultatet ska se ut så här:

Analys av sammanslagningsförfrågningar i GitLab med PVS-Studio för C#
Nu kan du gå vidare till analys. Låt oss först lägga till ett skript för en fullständig analys. Till flaggan -t vi passerar vägen till lösningen på flaggan -o skriv sökvägen till filen där analysresultaten ska skrivas. Vi är också intresserade av returkoden. I det här fallet är vi intresserade av att operationen stoppas när returkoden innehåller information om att varningar har utfärdats under analysen. Så här ser det här fragmentet ut:

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

Returkoder fungerar enligt principen om en bitmask. Till exempel, om varningar utfärdades som ett resultat av analysen, kommer returkoden att vara lika med 8. Om licensen löper ut inom en månad kommer returkoden att vara lika med 4. Om fel upptäcktes under analysen, och licensen löper ut inom en månad, koden returnerar, båda värdena kommer att skrivas: lägg ihop siffrorna och få den slutliga returkoden - 8+4=12. Genom att kontrollera motsvarande bitar kan således information om olika tillstånd erhållas under analys. Returkoder beskrivs mer i detalj i avsnittet "pvs-studio-dotnet (Linux / macOS) returkoder" i dokumentet "Kontrollera Visual Studio / MSBuild / .NET Core-projekt från kommandoraden med PVS-Studio".

I det här fallet är vi intresserade av alla returkoder där 8 visas.

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

Vi får 1 när returkoden innehåller biten av numret vi är intresserade av, annars får vi 0.

Det är dags att lägga till analys av sammanslagningsförfrågningar. Innan vi gör detta, låt oss förbereda en plats för manuset. Vi behöver bara köra det när en sammanslagningsbegäran inträffar. Det ser ut så här:

merge:
  script:
  only:
  - merge_requests

Låt oss gå vidare till själva manuset. Jag stod inför det faktum att den virtuella maskinen inte vet något om ursprung / mästare. Så låt oss hjälpa henne lite:

  - git fetch origin

Nu får vi skillnaden mellan grenarna och sparar resultatet in Text fil:

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

var $CI_COMMIT_SHA – hash av den senaste commit.

Därefter börjar vi analysera listan över filer med flaggan -f. Vi överför den tidigare mottagna .txt-filen till den. Tja, analogt med den fullständiga analysen tittar vi på returkoderna:

  - 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

Det fullständiga skriptet för att kontrollera en sammanslagningsförfrågan kommer att se ut så här:

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

Allt som återstår är att lägga till loggkonvertering efter att alla skript har bearbetats. Vi använder etiketten efter_skript och nytta plog-omvandlare:

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

Verktyg plog-omvandlare är ett projekt med öppen källkod som används för att konvertera parserfelrapporter till olika former, till exempel HTML. En mer detaljerad beskrivning av verktyget ges i underavsnittet "Plog Converter Utility" relevant avsnitt i dokumentationen.

Förresten, om du bekvämt vill arbeta med .json-rapporter lokalt från IDE, så föreslår jag vår plugin för IDE Rider. Dess användning beskrivs mer i detalj i relevant dokument.

För enkelhetens skull, här är den .gitlab-ci.yml i sin helhet:

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

När du har lagt till allt i filen klickar du på Begå ändringar. För att se att allt är korrekt, gå till CI / CD -> Rörledningar -> Springa. Ett virtuellt maskinfönster öppnas, i slutet av vilket det bör finnas följande:

Analys av sammanslagningsförfrågningar i GitLab med PVS-Studio för C#
fick syn på Job lyckades - framgång, allt är bra. Nu kan du testa vad du har gjort.

Exempel på arbete

För ett exempel på arbete, låt oss skapa ett enkelt projekt (i Master) som kommer att innehålla flera filer. Efter det, i en annan gren kommer vi bara att ändra en fil och försöka göra en sammanfogningsförfrågan.

Låt oss överväga två fall: när den ändrade filen innehåller ett fel och när den inte gör det. Först ett exempel med ett fel.

Låt oss säga att det finns en fil i mastergrenen Program.cs, som inte innehåller fel, men i en annan gren har utvecklaren lagt till felaktig kod och vill göra en sammanslagningsförfrågan. Vilken typ av misstag han gjorde är inte så viktigt, huvudsaken är att det finns. Till exempel glömde operatören kasta (Ja, så fel):

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

Låt oss titta på resultatet av att analysera ett exempel med ett fel. För att vara säker på att bara en fil analyserades lade jag till flaggan -r till pvs-studio-dotnet lanseringslinje:

Analys av sammanslagningsförfrågningar i GitLab med PVS-Studio för C#
Vi ser att analysatorn hittade ett fel och inte tillät sammanslagning av grenar.

Låt oss kolla exemplet utan fel. Korrigera koden:

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

Sammanfoga resultat för begäran om analys:

Analys av sammanslagningsförfrågningar i GitLab med PVS-Studio för C#
Som vi kan se hittades inga fel, och uppgiftsexekveringen lyckades, vilket är vad vi ville kontrollera.

Slutsats

Att rensa bort dålig kod innan man slår ihop grenar är väldigt bekvämt och trevligt. Så om du använder CI/CD, försök att bädda in en statisk analysator för att kontrollera. Dessutom görs detta helt enkelt.

Tack för er uppmärksamhet.

Analys av sammanslagningsförfrågningar i GitLab med PVS-Studio för C#
Om du vill dela den här artikeln med en engelsktalande publik, använd gärna översättningslänken: Nikolay Mironov. Analys av sammanslagningsförfrågningar i GitLab med PVS-Studio för C#.

Källa: will.com

Lägg en kommentar