🥇Analyse af fusionsanmodninger i GitLab ved hjælp af PVS-Studio til C#

Elsker GitLab og hader fejl? Vil du forbedre kvaliteten af din kildekode? Så er du kommet til det rigtige sted. I dag vil vi fortælle dig, hvordan du konfigurerer PVS-Studio C#-analysatoren til at kontrollere fusionsanmodninger. Skål til alle og god læsning.

PVS Studio er et værktøj til at opdage fejl og potentielle sårbarheder i kildekoden til programmer skrevet i C, C++, C# og Java. Virker på 64-bit systemer på Windows, Linux og macOS. Kan analysere kode designet til 32-bit, 64-bit og indlejrede ARM-platforme.

Vi har i øvrigt udgivet PVS-Studio 7.08, hvor vi har lavet en masse ting interessant. For eksempel:

C# analysator til Linux og macOS;
plugin til Rider;
ny fillistekontroltilstand.

Kontroltilstand for filliste

Tidligere var det nødvendigt at sende en .xml-fil med en liste over filer til parseren for at kontrollere visse filer. Men da dette ikke er særlig praktisk, har vi tilføjet muligheden for at overføre .txt, hvilket i høj grad forenkler livet.

For at kontrollere visse filer skal du angive flaget --kildefiler (-f) og send .txt med en liste over filer. Det ser sådan ud:

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

Hvis du er interesseret i at konfigurere commit-checks eller pull-anmodninger, kan du også gøre det ved at bruge denne tilstand. Forskellen vil være i at få en liste over filer til analyse og vil afhænge af hvilke systemer du bruger.

Princippet for kontrol af fusionsanmodninger

Hovedessensen af kontrollen er at sikre, at de problemer, der er opdaget af analysatoren, ikke falder ind i fusionen Master afdeling. Vi ønsker heller ikke at analysere hele projektet hver gang. Desuden har vi, når vi slår filialer sammen, en liste over ændrede filer. Derfor foreslår jeg at tilføje en fletningsanmodningskontrol.

Sådan ser sammenlægningsanmodningen ud før introduktionen af den statiske analysator:

Altså alle de fejl der var i grenen ændringer, vil flytte til mastergrenen. Da vi ikke ønsker dette, tilføjer vi analysen, og nu ser kredsløbet således ud:

Vi analyserer ændringer 2 og hvis der ikke er nogen fejl, accepterer vi anmodningen om fletning, ellers afviser vi den.

Hvis du i øvrigt er interesseret i at analysere commits og pull requests for C/C++, så kan du læse om det. her.

GitLab

GitLab er et open source DevOps-livscykluswebværktøj, der giver et kodelagerstyringssystem til Git med sin egen wiki, fejlsporingssystem, CI/CD-pipeline og andre funktioner.

Før du fortsætter med implementeringen af analysen af fletteanmodninger, skal du registrere og uploade dit projekt. Hvis du ikke ved, hvordan du gør dette, så foreslår jeg en artikel min kollega.

Bemærk. Måden at opsætte miljøet beskrevet nedenfor er en af de mulige. Målet er at vise trinene til opsætning af det nødvendige miljø til analyse og lancering af analysatoren. Måske, i dit tilfælde, ville det være mere optimalt at adskille stadierne af miljøforberedelse (tilføje depoter, installere analysatoren) og analyse: for eksempel forberede Docker-billeder med det nødvendige miljø og bruge dem eller på anden måde.

For bedre at forstå, hvad der vil ske nu, foreslår jeg, at du tager et kig på følgende diagram:

Analysatoren kræver, at .NET Core SDK 3 fungerer, så før du installerer analysatoren, skal du tilføje Microsoft-lagrene, hvorfra de nødvendige afhængigheder til analysatoren vil blive installeret. Tilføjelse af Microsoft-depoter til forskellige Linux-distributioner beskrevet i det relevante dokument.

For at installere PVS-Studio via pakkehåndteringen, skal du også tilføje PVS-Studio-lagrene. Tilføjelse af repositories til forskellige distributioner er beskrevet mere detaljeret i tilsvarende afsnit af dokumentationen.

Analysatoren skal have en licensnøgle for at fungere. Du kan få en prøvelicens på analysator download side.

Bemærk. Bemærk venligst, at den beskrevne funktionsmåde (analyse af fletningsanmodninger) kræver en Enterprise-licens. Derfor, hvis du vil prøve denne funktionsmåde, skal du i feltet "Besked" ikke glemme at angive, at du har brug for en Enterprise-licens.

Hvis der opstår en fusionsanmodning, skal vi kun analysere listen over ændrede filer, ellers analyserer vi alle filer. Efter analyse skal vi konvertere logfilerne til det format, vi har brug for.

Nu med arbejdets algoritme for øjnene af os, kan vi fortsætte med at skrive scriptet. For at gøre dette skal du ændre filen .gitlab-ci.yml eller, hvis det ikke eksisterer, opret det. For at oprette det, skal du klikke på navnet på dit projekt -> Opsæt CI/CD.

Nu er vi klar til at skrive manuskriptet. Lad os først skrive koden, der installerer analysatoren og indtaste 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

Da installation og aktivering skal ske før alle andre scripts, bruger vi en speciel etiket før_script. Lad mig forklare denne del lidt.

Forberedelse til installation af analysatoren:

  - 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

Tilføjelse af PVS-Studio og analysatorlagre:

  - 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 - Brugernavn.

$PVS_KEY - produktnøgle.

Gendan projektafhængigheder hvor $CI_PROJECT_DIR – fuld sti til projektbiblioteket:

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

For korrekt analyse skal projektet bygges med succes, og dets afhængigheder skal gendannes (for eksempel skal de nødvendige NuGet-pakker downloades).

Du kan indstille miljøvariabler, der indeholder licensoplysninger, ved at klikke på Lokal område, og efter-på CI/CD.

Find elementet i vinduet, der åbnes Variabler, højreklik på knappen Udvid og tilføje variabler. Resultatet skal være følgende:

Nu kan vi gå videre til analysen. Lad os først tilføje et script til en komplet analyse. Til flaget -t passere vejen til løsning til flaget -o skriv stien til den fil, hvor analyseresultaterne vil blive skrevet. Vi er også interesserede i returkoden. I dette tilfælde er vi interesserede i at stoppe arbejdet, når returkoden indeholder oplysninger om, at der er udstedt advarsler under analysen. Sådan ser uddraget ud:

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 fungerer efter princippet om en bitmaske. Hvis der f.eks. blev udstedt advarsler som følge af analysen, vil returkoden være 8. Hvis licensen udløber inden for en måned, vil returkoden være 4. Hvis der blev fundet fejl under analysen, og licensen også udløber inden for en måned, koden returnerer, begge værdier vil blive skrevet: læg tallene sammen og få den endelige returkode - 8 + 4 = 12. Ved at kontrollere de tilsvarende bits er det således muligt at få information om forskellige tilstande under analyse. Returkoder er beskrevet mere detaljeret i pvs-studio-dotnet (Linux / macOS) Returkoder sektionen af dokumentet.Kontrol af Visual Studio / MSBuild / .NET Core-projekter fra kommandolinjen ved hjælp af PVS-Studio".

I dette tilfælde er vi interesserede i alle returkoder, hvor 8 står.

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

Vi får 1, når returkoden indeholder den bit af tallet, vi er interesseret i, ellers får vi 0.

Det er på tide at tilføje fletteanmodningsanalysen. Før du gør dette, lad os forberede et sted til scriptet. Vi har kun brug for, at det udføres, når der opstår en fletteanmodning. Det ser sådan ud:

merge:
  script:
  only:
  - merge_requests

Lad os gå videre til selve manuskriptet. Jeg stødte på det faktum, at den virtuelle maskine ikke ved noget om oprindelse/mester. Så lad os hjælpe hende lidt:

  - git fetch origin

Nu får vi forskellen på grenene og gemmer resultatet ind txt fil:

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

hvor $CI_COMMIT_SHA – hash af den sidste commit.

Dernæst starter vi analysen af listen over filer ved hjælp af flaget -f. Vi overfører den tidligere modtagne .txt-fil til den. Nå, analogt med den fulde analyse ser vi på returkoderne:

  - 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 komplette script til kontrol af fletteanmodningen vil se sådan ud:

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 er kun tilbage at tilføje logkonverteringen, når alle scripts har fungeret. Brug af etiketten efter_script og nytte plog-konverter:

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

Hjælpeprogram plog-konverter er et open source-projekt, der bruges til at konvertere parser-fejlrapporten til forskellige former, såsom HTML. For en mere detaljeret beskrivelse af hjælpeprogrammet, se underafsnittet "Plog Converter Utility". tilsvarende afsnit af dokumentationen.

Forresten, hvis du bekvemt vil arbejde med en .json-rapport lokalt fra IDE, så foreslår jeg vores plugin til IDE Rider. Dens brug er beskrevet mere detaljeret i relevant dokument.

For nemheds skyld her .gitlab-ci.yml hel:

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 alt er tilføjet til filen, skal du klikke på begå ændringer. Gå til for at se, om alt er korrekt CI / CD -> Rørledninger -> Løb. Vinduet med den virtuelle maskine åbnes, og i slutningen heraf skal følgende være:

sav Job lykkedes - succes, alt er fint. Nu kan du teste, hvad du har gjort.

Eksempler på arbejde

For et eksempel på arbejde, lad os oprette et simpelt projekt (i Master), som vil indeholde flere filer. Derefter vil vi i en anden gren kun ændre én fil og forsøge at lave en fletteanmodning.

Lad os overveje to tilfælde: når den ændrede fil indeholder en fejl, og når den ikke gør. Først et eksempel med en fejl.

Lad os sige, at der er en fil i mastergrenen Program.cs, som ikke indeholder fejl, og i en anden gren tilføjede udvikleren fejlagtig kode og ønsker at lave en fletteanmodning. Hvilken slags fejl, han lavede, er ikke så vigtig, det vigtigste er, at den eksisterer. For eksempel glemte jeg operatøren kaste (Ja, så forkert):

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

Lad os se på resultatet af analysen af et eksempel med en fejl. Også for at sikre, at kun én fil blev parset, tilføjede jeg flaget -r til pvs-studio-dotnet startlinjen:

Vi ser, at analysatoren fandt en fejl og tillod ikke, at grenene blev slået sammen.

Lad os tjekke eksemplet uden fejl. Ret koden:

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

Resultater af fusionsanmodningsanalyse:

Som vi kan se, blev der ikke fundet fejl, og udførelsen af opgaven lykkedes, hvilket vi gerne ville kontrollere.

Konklusion

Det er meget bekvemt og behageligt at luge dårlig kode ud før sammenlægning af grene. Derfor, hvis du bruger CI/CD, så prøv at integrere en statisk analysator for at kontrollere det. Desuden gøres dette ganske enkelt.

Tak for din opmærksomhed.

Hvis du vil dele denne artikel med et engelsktalende publikum, så brug venligst oversættelseslinket: Nikolay Mironov. Analyse af fusionsanmodninger i GitLab ved hjælp af PVS-Studio for C#.

Kilde: www.habr.com

Analyse af fusionsanmodninger i GitLab ved hjælp af PVS-Studio til C#

Kontroltilstand for filliste

Princippet for kontrol af fusionsanmodninger

GitLab

Eksempler på arbejde

Konklusion

Tilføj en kommentar Annuller svar