🥇Analyse av merge requests i GitLab med PVS-Studio for C#

Elsker du GitLab og hater feil? Vil du forbedre kvaliteten på kildekoden? Da har du kommet til rett sted. I dag skal vi fortelle hvordan du setter opp C#-analysatoren PVS-Studio for å sjekke merge request'er. Ønsker alle et enestående humør og god lesning.

PVS-Studio - er et verktøy for å avdekke feil og potensielle sårbarheter i kildekoden til programmer skrevet i språk som C, C++, C# og Java. Det fungerer på 64-biters systemer med Windows, Linux og macOS. Kan analysere kode beregnet for 32-biters, 64-biters og innebygde ARM-plattformer.

Forresten, vi har sluppet PVS-Studio 7.08, der vi har gjort mye spennende. interessante ting. For eksempel:

C#-analysator for Linux og macOS;
plugin for Rider;
ny modus for å sjekke filoversikter.

Modus for sjekk av filListe

Tidligere for å sjekke bestemte filer måtte man overlevere en .xml med filene til analysatoren. Men siden dette ikke er så praktisk, har vi lagt til muligheten til å overlevere en .txt, noe som forenkler livet betydelig.

For å sjekke bestemte filer må du spesifisere flagget —sourceFiles (for streaming av logger) og) og overlevere en .txt med filoversikten. Det ser slik ut:

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

Hvis du er interessert i å sette opp sjekk av commits eller pull requests, kan du også gjøre dette ved å bruke denne modusen. Forskjellen vil ligge i hvordan filoversikten for analysen hentes og avhenge av hvilke systemer du bruker.

Prinsippet for å sjekke merge request

Hovedpoenget med sjekken er at problemene som analysatoren avdekker, ikke havner i master grenen når det slås sammen. Vi ønsker heller ikke å analysere prosjektet i sin helhet hver gang. Dessuten har vi en liste over endrede filer ved sammenslåing av grener. Derfor foreslår jeg å legge til sjekk på merge request.

Slik ser en merge request ut før den statiske analysatoren er implementert:

Det vil si at alle feil som var i grenen endringer, vil gå til mastergrenen. Siden vi ikke ønsker dette, legger vi til analyser, og nå ser ordningen slik ut:

Vi analyserer changes2 og hvis det ikke er feil, aksepterer vi merge request'en, ellers avviser vi den.

Forresten, hvis du er interessert i analyse av commits og pull request'er for C/C++, kan du lese om dette her.

GitLab

GitLab - et DevOps livssyklus webverktøy med åpen kildekode, som representerer et system for kilderepositorier for Git med egen wiki, feilsøking system, CI/CD pipeline og andre funksjoner.

Før vi begynner med implementeringen av analysen av merge requests, må du registrere deg og laste opp prosjektet ditt. Hvis du ikke vet hvordan du gjør dette, foreslår jeg artikkelen min kollega.

Merk. Metoden for å konfigurere miljøet som beskrives videre, er en av mulighetene. Målet er å vise trinnene for å konfigurere det nødvendige miljøet for analysen og kjøre analysatoren. Det kan hende at det er mer optimalt i ditt tilfelle å dele forberedelsesfasene av miljøet (legge til depoter, installere analysatoren) og analysen: for eksempel forberede Docker-bilder med nødvendig miljø og bruke dem eller en annen metode.

For bedre å forstå hva som nå vil skje, foreslår jeg at vi ser på følgende skjema:

For at analysatoren skal fungere, kreves .NET Core SDK 3, så før installasjon av analysatoren må du legge til Microsoft-depotene som de nødvendige avhengighetene for analysatoren skal installeres fra. Legg til Microsoft-depotene for forskjellige Linux-distribusjoner er beskrevet i det aktuelle dokumentet.

For å installere PVS-Studio via pakkeadministratoren må du også legge til PVS-Studio-depotene. Legg til depotene for de forskjellige distribusjonene er beskrevet mer detaljert i den aktuelle delen av dokumentasjonen.

For at analysatoren skal fungere, trengs en lisensnøkkel. Du kan få en prøve lisens på nedlastingssiden for analysatoren.

Merk. Vær oppmerksom på at for den beskrevne driftsmodusen (analyse av merge requests) kreves en Enterprise-lisens. Så hvis du ønsker å prøve denne driftsmodusen, må du huske å angi at du trenger nettopp en Enterprise-lisens i "Melding"-feltet.

Når det skjer en merge request, må vi bare analysere listen over endrede filer, ellers analyserer vi alle filene. Etter analysen må vi konvertere loggene til det formatet vi trenger.

Nå som vi har algoritmen foran oss, kan vi begynne å skrive skriptet. For å gjøre dette, må vi endre filen .gitlab-ci.yml eller, hvis den ikke eksisterer, opprette den. For å opprette den må du klikke på navnet på prosjektet ditt -> Set up CI/CD.

Nå er vi klare til å skrive skriptet. La oss først skrive koden som installerer analysatoren og legger inn lisensen:

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

Siden installasjonen og aktiveringen må skje før alle andre skript, bruker vi en spesiell etikett before_script. La meg forklare denne delen.

Forberedelse for installasjonen av 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

Legger til PVS-Studio-repositorier og analysatoren:

  - 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 lisens:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME — brukernavn.

$PVS_KEY — produktnøkkel.

Gjenoppretting av prosjektavhengigheter der $CI_PROJECT_DIR – den fullstendige banen til prosjektkatalogen:

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

For korrekt analyse må prosjektet bygges vellykket, og dets avhengigheter må være gjenopprettet (for eksempel må nødvendige NuGet-pakker lastes ned).

For å angi miljøvariabler som inneholder lisensinformasjon, kan du klikke på Setting, og deretter — på CI / CD.

I det åpne vinduet finner vi alternativet Variabler, og deretter klikker vi på knappen Expand og legger til variablene. Resultatet skal bli som følger:

Nå kan vi gå videre til analysen. Først legger vi til skriptet for full analyse. I flagget -t overfører vi banen til løsningen, i flagget -o angir vi banen til filen der analyse-resultatene skal lagres. Vi er også interessert i returkode. I dette tilfellet vil vi at jobben skal stopper når returkoden indikerer at det under analysen ble gitt advarsler. Slik ser denne delen 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

Returkkodar fungerer på prinsippet om bitmaske. For eksempel, hvis analysen har gitt advarsler, blir returkkoden lik 8. Hvis lisensen utløper i løpet av en måned, blir returkkoden lik 4. Hvis analysen derimot oppdager feil, og lisensen utløper i løpet av en måned, vil begge verdiene bli skrevet inn i returkkoden: summer tallene sammen og vi får den totale returkkoden - 8+4=12. Dermed kan vi ved å sjekke de relevante bitene hente informasjon om forskjellige tilstander under analysen. Returkkodene er mer detaljert beskrevet i seksjonen "Returkkoder pvs-studio-dotnet (Linux / macOS)" i dokumentet.Sjekk av Visual Studio / MSBuild / .NET Core prosjekter fra kommandolinjen ved hjelp av PVS-Studio.".

I dette tilfellet er vi interessert i alle returkoder som inneholder 8.

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

Vi får 1 når returkkoden inneholder den biten av tallet vi er interessert i, ellers får vi 0.

Det er på tide å legge til analysen av merge request. Før vi gjør dette, forbereder vi et sted for skriptet. Vi trenger at det kun kjøres når en merge request skjer. Det ser slik ut:

merge:
  script:
  only:
  - merge_requests

La oss gå til selve skriptet. Jeg har møtt på at den virtuelle maskinen ikke vet noe om origin/master. Derfor hjelper vi den litt:

  - git fetch origin

Nå får vi forskjellen mellom grenene og lagrer resultatet i txt fil:

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

Hvor $CI_COMMIT_SHA – hash for den siste commiten.

Deretter kjører vi analysen av filene, ved å bruke flagget for streaming av logger) og. Vi sender den tidligere oppnådde .txt-filen. Og på lignende måte, med full analysen, ser vi returkodene:

  - 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 skriptet for å sjekke merge requests vil se slik ut:

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 gjenstår bare å legge til konvertering av loggen etter at alle skriptene er kjørt. Vi bruker merket after_script og verktøyet plog-converter:

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

Verktøy plog-converter — er et open source-prosjekt som brukes til å konvertere feilmeldingsrapporter fra analyseverktøyet til ulike former, for eksempel HTML. En mer detaljert beskrivelse av verktøyet finnes i seksjonen "Plog Converter-verktøy" tilsvarende dokumentasjonsseksjon.

Forresten, hvis du ønsker en praktisk måte å jobbe med .json-rapporten lokalt fra IDE, så anbefaler jeg vår plugin for IDE Rider. Bruken er beskrevet mer detaljert i den aktuelle dokumentasjonen.

For enkelhets skyld er her .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 alt er lagt til i filen, klikker vi på Commit changes. For å sjekke at alt er korrekt, går vi til CI/CD -> Pipelines -> Running. Et vindu med den virtuelle maskinen åpnes, hvor du til slutt bør se følgende:

Vi så Job succeeded – suksess, alt er flott. Nå kan vi teste det vi har gjort.

Eksempler på arbeid

Som et eksempel på arbeid skal vi lage et enkelt prosjekt (i master) hvor det vil være flere filer. Deretter vil vi i en annen gren kun endre én fil og prøve å lage en merge request.

La oss vurdere to tilfeller: når den endrede filen inneholder en feil, og når den ikke gjør det. Først et eksempel med en feil.

Anta at det i master-grenen er en fil Program.cs, som ikke inneholder feil, men i en annen gren har utvikleren lagt til feil kode og ønsker å lage en merge request. Hvilken nøyaktig feil han har gjort – er ikke så viktig, det viktigste er at det finnes en. For eksempel glemte han operatoren throw (ja, slik kan man feile):

void MyAwesomeMethod(String name)
{
  if (name == null)
    new ArgumentNullException(....);
  // gjør noe
  ....
}

La oss se på resultatet av analysen av eksempelet med en feil. For å være sikker på at bare én fil ble analysert, la jeg til flagget -r i oppstartstrengen for pvs-studio-dotnet:

Vi ser at analysatoren fant en feil og ikke lot merge-grenene gjennomføres.

La oss sjekke eksemplet uten feil. Vi retter koden:

void MyAwesomeMethod(String name)
{
  if (name == null)
    throw new ArgumentNullException(....);
  // gjør noe
  ....
}

Resultatene av analysen av merge request:

Som vi ser, ble det ikke funnet noen feil, og oppgaven ble utført vellykket, noe vi ønsket å verifisere.

Konklusjon

Å filtrere ut dårlig kode før sammenfletting av grener er både praktisk og behagelig. Så hvis du bruker CI/CD, bør du vurdere å integrere en statisk analyseverktøy for sjekking. Det er dessuten ganske enkelt å få til.

Takk for oppmerksomheten.

Hvis du ønsker å dele denne artikkelen med en engelskspråklig publikum, ber jeg deg bruke lenken til oversettelsen: Nikolay Mironov. Analysis of merge requests in GitLab using PVS-Studio for C#.

Kilde: habr.com

Analyse av merge requests i GitLab ved hjelp av PVS-Studio for C#

Modus for sjekk av filListe

Prinsippet for å sjekke merge request

GitLab

Eksempler på arbeid

Konklusjon