Analys av merge request:er i GitLab med hjälp av PVS-Studio för C#

Älskar du GitLab och avskyr du fel? Vill du förbättra kvaliteten på din källkod? Då har du kommit rätt. Idag berättar vi hur man konfigurerar C#-analysatorn PVS-Studio för att kontrollera merge-begärningar. Alla önskas en magisk stämning och trevlig läsning.

PVS-Studio — är ett verktyg för att identifiera fel och potentiella sårbarheter i källkoden för program skrivna på C, C++, C# och Java. Det fungerar i 64-bitars system på Windows, Linux och macOS. Det kan analysera kod avsedd för 32-bitars, 64-bitars och inbyggda ARM-plattformar.

För övrigt har vi släppt PVS-Studio 7.08, där vi har gjort mycket. intressant.Juniper (MX/QFX/ACX)

• C#-analysatorn för Linux och macOS;
• plugin för Rider;
• nytt läge för filkontroll.

Filkontrollläge

Tidigare var det nödvändigt att överföra en .xml med en lista över filer för att kontrollera specifika filer. Men eftersom det inte är särskilt bekvämt, har vi lagt till möjligheten att överföra .txt, vilket gör livet mycket enklare.

För att kontrollera specifika filer måste man ange flaggan —sourceFiles (-f) och överföra en .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 kontroll av commits eller pull requests kan du också göra det med detta läge. Skillnaden ligger i hur du får listan över filer att analysera och beror på vilka system du använder.

Principen för kontroll av merge-begärningar

Huvudsyftet med kontrollen är att problem som upptäckts av analysatorn inte ska hamna i master grenen vid sammanslagning. Vi vill inte heller analysera hela projektet varje gång. Speciellt eftersom vi vid sammanslagning av grenar har en lista över ändrade filer. Därför föreslår jag att vi lägger till kontroll av merge-begärningar.

Så här ser en merge-begäran ut före införandet av den statiska analysatorn:

Det vill säga alla fel som fanns i grenen changeskommer att överföras till huvudgrenen. Eftersom vi inte vill ha det så, lägger vi till analys, och nu ser schemat ut så här:

Vi analyserar changes2 och om det inte finns några fel accepterar vi merge-begäran, annars avvisar vi den.

För övrigt, om du är intresserad av analys av commits och pull requests för C/C++, kan du läsa om det här. här.

GitLab

GitLab — ett webbaserat DevOps-livscykelverktyg med öppen källkod som erbjuder ett källkodshanteringssystem för Git med en egen wiki, system för buggrapportering, CI/CD-pipeline och andra funktioner.

Innan vi påbörjar analysen av merge request:er måste du registrera dig och ladda upp ditt projekt. Om du inte vet hur du gör detta kan jag föreslå artikeln min kollega.

Anmärkning. Metoden som beskrivs nedan för att ställa in miljön är en av många möjliga. Målet är att visa stegen för att ställa in den nödvändiga miljön för analys och starta analyzern. I ditt fall kan det vara mer optimalt att dela upp stegen för att förbereda miljön (lägga till repositoryn, installera analyzern) och analys: till exempel förberedelse av Docker-bilder med nödvändig miljö och deras användning eller någon annan metod.

För att mer tydligt förstå vad som kommer att hända, föreslår jag att vi ser på följande schema:

För att analyzern ska fungera krävs .NET Core SDK 3, så innan vi installerar analyzern måste vi lägga till Microsoft-repositoryn där nödvändiga beroenden för analyzern kommer att installeras. Tillägg av Microsoft-repositoryn för olika Linux-distributioner beskrivs i den tillhörande dokumentationen..

För att installera PVS-Studio via paketförvaltaren måste vi också lägga till PVS-Studio-repositoryn. Tillägg av repositoryn för olika distributioner beskrivs mer ingående i den relevanta delen av dokumentationen..

För att analyzern ska fungera krävs en licensnyckel. Du kan få en provlicens på nedladdningssidan för analyzern..

Anmärkning. Observera att för den beskrivna driftsättningsmetoden (analys av merge requests) krävs en Enterprise-licens. Så om du vill prova denna driftsättningsmetod, kom ihåg att ange att du behöver just en Enterprise-licens i fältet "Meddelande".

Om det sker en merge request behöver vi bara analysera listan över ändrade filer, annars analyserar vi alla filer. Efter analysen måste vi konvertera loggarna till det format vi behöver.

Nu, med arbetsalgoritmen i åtanke, kan vi börja skriva skriptet. För att göra detta måste vi ändra filen .gitlab-ci.yml eller, om den inte finns, skapa den. För att skapa den klickar du på namnet på ditt projekt -> Ställ in CI/CD.

Nu är vi redo att börja skriva skriptet. Låt oss först skriva koden som kommer att installera analyzern 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 installationen och aktiveringen ska ske före alla andra skript använder vi en speciell märkning before_script. Jag ska förklara denna sektion lite mer.

Förberedelse för att installera 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ägg till PVS-Studio- och analysator-repositorier:

  - 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

Aktivering av licens:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME — användarnamn.

$PVS_KEY — produktnyckel.

Återställning av projektberoenden där $CI_PROJECT_DIR – fullständig väg till projektkatalogen:

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

För att korrekt kunna analysera måste projektet byggas utan fel och dess beroenden måste vara återställda (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 på Inställning, och sedan på CI / CD.

I det öppna fönstret hittar vi punkten Variabler, klicka till höger på knappen Expandera och lägg till variabler. Det borde resultera i följande:

Nu kan vi gå vidare till analysen. Först lägger vi till skriptet för en fullständig analys. I flaggan -t anger vi vägen till lösningen, i flaggan -o anger vi vägen till filen där analysresultaten ska skrivas. Vi är också intresserade av returkoden. I det här fallet är vi intresserade av att processen stoppas när returkoden indikerar att varningar gavs under analysen. Så här ser denna sektion 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 för bitmaskar. Till exempel, om varningar utfärdas som resultat av analysen kommer returkoden att vara 8. Om licensen löper ut inom en månad kommer returkoden att vara 4. Om analysen upptäcker fel och licensen dessutom löper ut inom en månad, kommer båda värdena att inkluderas i returkoden: vi adderar siffrorna och får den slutliga returkoden — 8+4=12. Genom att kontrollera de relevanta bitarna kan vi få information om olika tillstånd under analysen. Returkoderna beskrivs mer ingående i avsnittet "Returkoder för pvs-studio-dotnet (Linux / macOS)" i dokumentet "Kontroll av Visual Studio / MSBuild / .NET Core-projekt från kommandoraden med hjälp av PVS-Studio".

I det här fallet är vi intresserade av alla returkoder som innehåller 8.

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

Vi får 1 när returkoden innehåller den bit av nummer som intresserar oss, annars får vi 0.

Det är dags att lägga till analys av merge request. Innan vi gör det förbereder vi plats för skriptet. Vi behöver att det bara körs när en merge request görs. Det ser ut så här:

merge:
  script:
  only:
  - merge_requests

Låt oss gå vidare till själva skriptet. Jag stötte på att den virtuella maskinen inte vet något om origin/master. Därför hjälper vi den lite:

  - git fetch origin

Nu ska vi få skillnaden mellan grenarna och spara resultatet i txt fil:

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

Där $CI_COMMIT_SHA – hash för den senaste commiten.

Därefter kör vi analysen av filerna, med hjälp av flaggan -f. Vi skickar in den tidigare erhållna .txt-filen. Och på samma sätt som med den fullständiga analysen kontrollerar vi 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 merge request ser 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

Det återstår bara att lägga till konvertering av loggen efter att alla skript har körts. Använd etiketten after_script och verktyget plog-converter:

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

Verktyg plog-converter — ett open source-projekt som används för att konvertera felrapporten från analysatorn till olika format, till exempel HTML. En mer detaljerad beskrivning av verktyget finns i avsnittet "Plog Converter Utility" den motsvarande avsnittet i dokumentationen.

För övrigt, om du vill arbeta bekvämt med .json-rapporten lokalt från IDE, föreslår jag vår plugin för IDE Rider. En mer detaljerad användning beskrivs i det motsvarande dokumentet.

För bekvämlighetens skull här är .gitlab-ci.yml hela:

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

Så snart vi lagt till allt i filen, klickar vi på Commit changes. För att se att allt är korrekt, går vi in i CI/CD -> Pipeline -> Running. Ett fönster för den virtuella maskinen öppnas där det vid slutet ska stå följande:

Vi såg Job succeeded – framgång, allt är utmärkt. Nu kan vi testa det som gjorts.

Exempel på arbete

Som ett arbets exempel kommer vi att skapa ett enkelt projekt (i master) där det kommer att finnas flera filer. Efter detta ändrar vi endast en fil i en annan gren och försöker göra en merge-begäran.

Vi överväger två fall: när den ändrade filen innehåller ett fel och när den inte gör det. Först exemplet med ett fel.

Anta att det i master-grenen finns en fil Program.cs, som inte innehåller några fel, men i en annan gren har utvecklaren lagt till felaktig kod och vill göra en merge-begäran. Vilket fel han har gjort spelar mindre roll – det viktiga är att det finns. Till exempel glömde han operatorn throw (ja, så gör man misstag):

void MyAwesomeMethod(String name)
{
  if (name == null)
    new ArgumentNullException(....);
  // gör något
  ....
}

Låt oss titta på resultatet av analysen av exemplet med fel. För att också försäkra oss om att endast en fil analyserades har jag lagt till flaggan -r i kommandoraden för pvs-studio-dotnet:

Vi ser att analysatorn har hittat ett fel och inte tillåtit en sammanslagning av grenarna.

Vi kontrollerar exemplet utan fel. Koden korrigeras:

void MyAwesomeMethod(String name)
{
  if (name == null)
    throw new ArgumentNullException(....);
  // gör något
  ....
}

Resultat av analysen av merge-begäran:

Som vi ser har inga fel hittats och uppgiften har genomförts framgångsrikt, vilket vi ville kontrollera.

Slutsats

Att filtrera bort dålig kod före sammanslagning av grenar är mycket bekvämt och trevligt. Så om du använder CI/CD, försök integrera en statisk analysator för kontroll. Dessutom görs det ganska enkelt.

Tack för uppmärksamheten.

Om du vill dela den här artikeln med en engelsktalande publik, vänligen använd länken till översättningen: Nikolay Mironov. Analys av merge-begärningar i GitLab med PVS-Studio för C#.

Källa: habr.com