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

Elsker du GitLab og hader fejl? Vil du forbedre kvaliteten af din kildekode? Så er du kommet til det rette sted. I dag vil vi fortælle, hvordan du kan indstille C#-analysatoren PVS-Studio til at kontrollere merge requests. Ønsker dig en god læseoplevelse med et glitrende humør.

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. Det fungerer på 64-bit systemer på Windows, Linux og macOS. Det kan analysere kode beregnet til 32-bit, 64-bit og indlejrede ARM-platforme.

For øvrigt har vi lanceret PVS-Studio 7.08, hvor vi har lavet mange spændende funktioner. spændende ting. For eksempel:

• C#-analysator til Linux og macOS;
• plugin til Rider;
• ny tilstand for filkontrol.

Filkontrol-tilstand

Tidligere skulle man for at kontrollere bestemte filer give analysatoren en .xml med en liste over filer. Men da det ikke var særlig praktisk, har vi tilføjet muligheden for at give en .txt, hvilket gør livet meget enklere.

For at kontrollere bestemte filer skal du angive flaget --sourceFiles (-f) og give en .txt med en liste over filer. Det ser således ud:

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

Hvis du er interesseret i at indstille kontrol af commits eller pull requests, kan du også gøre det ved hjælp af denne tilstand. Forskellen vil være i at få listen over filer til analyse og afhænger af, hvilke systemer du bruger.

Princippet for kontrol af merge requests

Hovedideen med kontrollen er, at problemer, der opdages af analysatoren, ikke bør komme ind i master grenen ved sammenlægning. Desuden ønsker vi ikke at analysere hele projektet hver gang. Især fordi vi har en liste over ændrede filer ved sammenlægning af grene. Derfor foreslår jeg at tilføje kontrol af merge requests.

Sådan ser en merge request ud før implementering af den statiske analyser:

Det vil sige, at alle fejl, der var i grenen changes, vil komme ind i master-grenen. Da vi ikke ønsker dette, tilføjer vi analysen, og nu ser skemaet således ud:

Vi analyserer changes2 og, hvis der ikke er fejl, accepterer vi merge request, ellers afviser vi den.

For øvrigt, hvis du er interesseret i analyse af commits og pull requests for C/C++, kan du læse mere om dette. her.

GitLab

GitLab — et open source DevOps livscyklustool, der repræsenterer et versionskontrolsystem for Git med en egen wiki, fejlsporingssystem, CI/CD-pipeline og andre funktioner.

Før du går i gang med at implementere analysen af merge requests, skal du registrere dig og uploade dit projekt. Hvis du ikke ved, hvordan du gør det, kan jeg foreslå artiklen fra min kollega.

Bemærk. Metoden til at konfigurere miljøet, som beskrives nedenfor, er blot én mulighed. Målet er at vise trinene til at konfigurere et nødvendigt miljø for analysen og køre analysatoren. Det kan være, at det i dit tilfælde er mere optimalt at opdele forberedelsesfaserne (tilføjelse af repositories, installation af analysatoren) og analysen: for eksempel at forberede Docker-billeder med det nødvendige miljø og bruge dem eller en anden metode.

For at forstå, hvad der vil ske nu, foreslår jeg at se på følgende skema:

For at analysatoren kan fungere, kræves .NET Core SDK 3, så før installationen af analysatoren skal Microsoft repositories tilføjes, hvorfra de afhængigheder, der er nødvendige for analysatoren, vil blive installeret. Tilføjelse af Microsoft repositories til forskellige Linux-distributioner er beskrevet i det relevante dokument.

For at installere PVS-Studio via en package manager kræves det også at tilføje PVS-Studio repositories. Tilføjelse af repositories til forskellige distributioner er mere detaljeret beskrevet i den relevante sektion af dokumentationen.

For at analysatoren kan fungere, kræves der en licensnøgle. Du kan få en prøve licens på download-siden for analysatoren.

Bemærk. Vær opmærksom på, at der kræves en Enterprise-licens for den beskrevne driftsform (analyse af merge requests). Så hvis du ønsker at prøve denne driftsform, skal du i feltet "Besked" huske at angive, at du har brug for netop en Enterprise-licens.

Hvis der er et merge request, skal vi kun analysere listen over ændrede filer, ellers analyserer vi alle filer. Efter analysen skal loggene konverteres til det format, vi har brug for.

Nu, med arbejdsgangen i tankerne, kan vi gå videre til at skrive scriptet. For at gøre dette skal vi ændre filen .gitlab-ci.yml eller, hvis den ikke findes, oprette den. For at oprette den skal du klikke på navnet på dit projekt -> Opsæt CI/CD.

Nu er vi klar til at skrive scriptet. Lad os først skrive koden, der installerer analysatoren og indlæser 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 installationen og aktiveringen skal finde sted før alle andre scripts, bruger vi et specielt mærke before_script. Jeg vil kort forklare dette fragment.

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 analysatorens repositories:

  - 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 af licens:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME — brugernavn.

$PVS_KEY — produktnøgle.

Gendannelse af projektets afhængigheder, hvor $CI_PROJECT_DIR – den fulde sti til projektmappen:

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

For korrekt analyse skal projektet kunne bygges, og dets afhængigheder skal være blevet gendannet (f.eks. skal nødvendige NuGet-pakker være blevet downloadet).

Du kan angive miljøvariabler, som indeholder licensinformation, ved at klikke på Indstillinger, og derefter på CI / CD.

I det åbne vindue finder vi punktet Variabler, og til højre klikker vi på knappen Udvid og tilføjer variabler. Resultatet skal være som følger:

Nu kan vi gå til analysen. Først tilføjer vi scriptet til den fulde analyse. I flaget -t angiver vi stien til løsningen, i flaget -o angiver vi stien til filen, hvor resultaterne af analysen skal gemmes. Vi er også interesserede i returkoden. I dette tilfælde vil vi gerne have, at arbejdet stopper, når returkoden indeholder information om, at der under analysen er givet advarsler. Sådan ser dette fragment 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

Return codes operate on the principle of bit masking. For example, if warnings were issued as a result of the analysis, the return code will be 8. If the license expires within a month, the return code will be 4. If errors were detected during the analysis and the license is expiring within a month, both values will be recorded in the return code: we add the numbers together to obtain the final return code — 8+4=12. Thus, by checking the relevant bits, information about various states during the analysis can be obtained. More details on return codes are described in the "Return codes pvs-studio-dotnet (Linux / macOS)" section of the documentation.Checking Visual Studio / MSBuild / .NET Core projects from the command line using PVS-Studio".

In this case, we are interested in all return codes where 8 is included.

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

We will get 1 when the return code contains the bit we are interested in, otherwise we will get 0.

It’s time to add merge request analysis. Before doing that, let’s prepare a place for the script. We need it to execute only when a merge request occurs. It looks like this:

merge:
  script:
  only:
  - merge_requests

Now let’s move on to the script itself. I encountered the issue that the virtual machine knows nothing about origin/master. Therefore, we help it a bit:

  - git fetch origin

Now we will get the difference between branches and save the result in txt file:

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

Where $CI_COMMIT_SHA – the hash of the last commit.

Next, we run the analysis of the file list using the flag -f. We pass the previously obtained .txt file to it. And similarly to the full analysis, we look at the return codes:

  - 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

The complete script for checking the merge request will look like this:

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

We just need to add log conversion after all the scripts have executed. We will use the label after_script and the utility plog-converter:

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

Utility plog-converter — er et open source projekt, der bruges til at konvertere fejlrapporter fra analizeren til forskellige formater, såsom HTML. En mere detaljeret beskrivelse af værktøjet findes i afsnittet "Plog Converter værktøj" den relevante dokumentation.

Forresten, hvis du vil arbejde bekvemt med .json-rapporten lokalt fra IDE, foreslår jeg vores plugin til IDE Rider. En mere detaljeret brugervejledning findes i det relevante dokument.

For nemheds skyld her er .gitlab-ci.yml i sin helhed:

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 har tilføjet alt til filen, klikker vi på Commit changes. For at se, om alt er korrekt, går vi til CI/CD -> Pipelines -> Kørende. Et vindue med den virtuelle maskine åbnes, og i slutningen burde der stå følgende:

Vi så Job succeeded – succes, alt er fint. Nu kan vi også teste det, vi har lavet.

Eksempler på arbejde

For eksempel vil vi oprette et simpelt projekt (i master) hvor der vil være flere filer. Herefter vil vi i en anden gren ændre kun én fil og prøve at lave en merge request.

Lad os se på to situationer: 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 i master-grenen er en fil Program.cs, som ikke indeholder fejl, mens udvikleren i en anden gren har tilføjet problematisk kode og ønsker at lave en merge request. Hvilken fejl han har lavet – er ikke så vigtigt, det vigtigste er, at der er én. For eksempel glemte han operatoren throw (ja, sådan fejler man):

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

Lad os se på resultatet af analysen af eksemplet med fejl. Også for at sikre, at kun én fil er blevet analyseret, har jeg tilføjet flaget -r til startlinjen for pvs-studio-dotnet:

Vi ser, at analizeren fandt en fejl og forhindrede sammenlægning af grene.

Lad os tjekke eksemplet uden fejl. Retter koden:

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

Resultaterne af analysen af merge request:

Som vi kan se, er der ikke fundet nogen fejl, og opgaveudførelsen er gået godt, hvilket vi ønskede at tjekke.

Konklusion

At filtrere dårligt kode før sammenlægning af grene er meget praktisk og behageligt. Derfor, hvis du bruger CI/CD, så prøv at integrere en statisk analyzer til kontrol. Især da det kan gøres ganske nemt.

Tak for opmærksomheden.

Hvis du ønsker at dele denne artikel med et engelsktalende publikum, bedes du bruge linket til oversættelsen: Nikolay Mironov. Analyse af merge requests i GitLab ved hjælp af PVS-Studio for C#.

Kilde: habr.com