Analyse av sammenslåingsforespørsler i GitLab ved bruk av PVS-Studio for C#

Elsker GitLab og hater insekter? Vil du forbedre kvaliteten på kildekoden din? Da har du kommet til rett sted. I dag vil vi fortelle deg hvordan du konfigurerer PVS-Studio C#-analysatoren for å sjekke sammenslåingsforespørsler. Ha enhjørningsstemning og god lesning til alle.

PVS-Studio er et verktøy for å identifisere feil og potensielle sårbarheter i kildekoden til programmer skrevet i C, C++, C# og Java. Fungerer på 64-bits systemer på Windows, Linux og macOS. Kan analysere kode designet for 32-biters, 64-biters og innebygde ARM-plattformer.

Vi ga forresten ut PVS-Studio 7.08, der vi gjorde mange ting interessant. For eksempel:

• C#-analysator for Linux og macOS;
• plugin for Rider;
• ny fillistekontrollmodus.

Kontrollmodus for filliste

Tidligere, for å sjekke visse filer, var det nødvendig å sende en .xml med en liste over filer til analysatoren. Men siden dette ikke er veldig praktisk, har vi lagt til muligheten til å overføre .txt, noe som gjør livet veldig enkelt.

For å sjekke spesifikke filer, må du spesifisere flagget --kildefiler (-f) og overføre .txt med en liste over filer. 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 commit-sjekking eller pull-forespørsler, kan du også gjøre det ved å bruke denne modusen. Forskjellen vil være i å få en liste over filer å analysere og vil avhenge av hvilke systemer du bruker.

Prinsippet om å kontrollere en sammenslåingsforespørsel

Hovedessensen av sjekken er å sikre at problemer oppdaget av analysatoren under sammenslåing ikke faller inn i Master gren. Vi ønsker heller ikke å analysere hele prosjektet hver gang. Dessuten, når vi slår sammen grener, har vi en liste over endrede filer. Derfor foreslår jeg at du legger til en sjekk for sammenslåingsforespørsel.

Slik ser en sammenslåingsforespørsel ut før du implementerer en statisk analysator:

Det vil si alle feilene som var i grenen endringer, vil flytte til hovedgrenen. Siden vi ikke vil ha dette, legger vi til analyse, og nå ser diagrammet slik ut:

Vi analyserer endringer 2 og hvis det ikke er noen feil, godtar vi sammenslåingsforespørselen, ellers avviser vi den.

Forresten, hvis du er interessert i å analysere commits og pull requests for C/C++, så kan du lese om det her.

GitLab

GitLab er et åpen kildekode nettbasert DevOps-livssyklusverktøy som gir et styringssystem for kodelager for Git med sin egen wiki, problemsporingssystem, CI/CD-pipeline og andre funksjoner.

Før du begynner å analysere sammenslåingsforespørsler, må du registrere og laste opp prosjektet ditt. Hvis du ikke vet hvordan du gjør dette, så foreslår jeg artikkel min kollega.

Note. Metoden for å sette opp miljøet beskrevet nedenfor er en av de mulige. Målet er å vise trinnene for å sette opp miljøet som er nødvendig for analyse og lansering av analysatoren. Kanskje i ditt tilfelle ville det være mer optimalt å skille stadiene med miljøforberedelse (legge til depoter, installere en analysator) og analyse: for eksempel å forberede Docker-bilder med det nødvendige miljøet og bruke dem, eller en annen metode.

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

Analysatoren krever .NET Core SDK 3 for å fungere, så før du installerer analysatoren må du legge til Microsoft-repositoriene der avhengighetene som kreves for analysatoren, vil bli installert. Legger til Microsoft-repositories for ulike Linux-distribusjoner beskrevet i det tilsvarende dokumentet.

For å installere PVS-Studio gjennom pakkebehandlingen, må du også legge til PVS-Studio-lagrene. Å legge til repositories for forskjellige distribusjoner er beskrevet mer detaljert i relevant del av dokumentasjonen.

Analysatoren krever en lisensnøkkel for å fungere. Du kan få prøvelisens på analysator nedlastingsside.

Note. Vær oppmerksom på at den beskrevne driftsmodusen (analyse av sammenslåingsforespørsler) krever en Enterprise-lisens. Derfor, hvis du vil prøve denne driftsmodusen, ikke glem å angi i "Melding"-feltet at du trenger en Enterprise-lisens.

Hvis det oppstår en sammenslåingsforespørsel, trenger vi bare å analysere listen over endrede filer, ellers analyserer vi alle filene. Etter analyse må vi konvertere loggene til det formatet vi trenger.

Nå, med algoritmen for arbeid foran øynene dine, kan du gå videre til å skrive et manus. For å gjøre dette må du endre filen .gitlab-ci.yml eller, hvis den ikke eksisterer, lag den. For å lage det, må du klikke på navnet på prosjektet ditt -> Sett opp CI/CD.

Nå er vi klare til å skrive manuset. La oss først skrive koden som skal installere analysatoren og legge 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 installasjon og aktivering må skje før alle andre skript, bruker vi en spesiell etikett før_skript. La meg forklare dette fragmentet litt.

Forbereder installasjon 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

Legge til PVS-Studio repositories og 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

Lisensaktivering:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME - Brukernavn.

$PVS_KEY - produktnøkkel.

Gjenopprette prosjektavhengigheter hvor $CI_PROJECT_DIR – full bane til prosjektkatalogen:

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

For korrekt analyse må prosjektet bygges vellykket, og dets avhengigheter må gjenopprettes (for eksempel må de nødvendige NuGet-pakkene lastes ned).

Du kan angi miljøvariabler som inneholder lisensinformasjon ved å klikke Stille, og etterpå CI/CD.

Finn elementet i vinduet som åpnes Variabler, klikk på knappen til høyre Expand og legg til variabler. Resultatet skal se slik ut:

Nå kan du gå videre til analyse. Først, la oss legge til et skript for en fullstendig analyse. Til flagget -t vi passerer veien til løsningen på flagget -o skriv stien til filen der analyseresultatene skal skrives. Vi er også interessert i returkoden. I dette tilfellet er vi interessert i at operasjonen stopper når returkoden inneholder informasjon om at det ble gitt advarsler under analysen. Slik ser dette 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 fungerer etter prinsippet om en bitmaske. For eksempel, hvis det ble gitt advarsler som et resultat av analysen, vil returkoden være lik 8. Hvis lisensen utløper innen en måned, vil returkoden være lik 4. Hvis det ble oppdaget feil under analysen, og lisensen utløper innen en måned, koden returnerer, begge verdiene vil bli skrevet: legg sammen tallene og få den endelige returkoden - 8+4=12. Ved å sjekke de korresponderende bitene kan informasjon om forskjellige tilstander oppnås under analyse. Returkoder er beskrevet mer detaljert i delen "pvs-studio-dotnet (Linux / macOS) Returkoder" i dokumentet "Sjekker Visual Studio / MSBuild / .NET Core-prosjekter fra kommandolinjen ved hjelp av PVS-Studio".

I dette tilfellet er vi interessert i alle returkoder der 8 vises.

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

Vi vil motta 1 når returkoden inneholder biten av nummeret vi er interessert i, ellers får vi 0.

Det er på tide å legge til analyse av sammenslåingsforespørsel. Før vi gjør dette, la oss forberede et sted for manuset. Vi trenger at den kun utføres når en sammenslåingsforespørsel oppstår. Det ser slik ut:

merge:
  script:
  only:
  - merge_requests

La oss gå videre til selve manuset. Jeg ble møtt med det faktum at den virtuelle maskinen ikke vet noe om opprinnelse / mester. Så la oss hjelpe henne litt:

  - git fetch origin

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

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

hvor $CI_COMMIT_SHA – hasj av siste commit.

Deretter begynner vi å analysere listen over filer ved å bruke flagget -f. Vi overfører den tidligere mottatte .txt-filen til den. Vel, analogt med hele analysen ser vi på 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 en sammenslåingsforespørsel 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

Alt som gjenstår er å legge til loggkonvertering etter at alle skriptene er behandlet. Vi bruker etiketten etter_skript og nytte plog-omformer:

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

Nytte plog-omformer er et åpen kildekode-prosjekt som brukes til å konvertere parserfeilrapporter til ulike former, for eksempel HTML. En mer detaljert beskrivelse av verktøyet er gitt i underavsnittet "Plog Converter Utility" relevant del av dokumentasjonen.

Forresten, hvis du enkelt vil jobbe med .json-rapporter lokalt fra IDE, så foreslår jeg vår plugg inn for IDE Rider. Bruken er beskrevet mer detaljert i relevant dokument.

For enkelhets skyld, her er 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 til alt i filen, klikk på Forplikte endringer. For å se at alt er riktig, gå til CI / CD -> Rørledninger -> kjører. Et virtuell maskinvindu åpnes, på slutten av dette skal det være følgende:

sag Job lyktes - suksess, alt er bra. Nå kan du teste hva du har gjort.

Arbeidseksempler

For et eksempel på arbeid, la oss lage et enkelt prosjekt (i Master) som vil inneholde flere filer. Etter det, i en annen gren, vil vi bare endre én fil og prøve å lage en sammenslåingsforespørsel.

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.

La oss si at det er en fil i mastergrenen Program.cs, som ikke inneholder feil, men i en annen gren la utvikleren til feil kode og ønsker å lage en sammenslåingsforespørsel. Hva slags feil han gjorde er ikke så viktig, hovedsaken er at den eksisterer. For eksempel glemte operatøren kaste (Ja, så feil):

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

La oss se på resultatet av å analysere et eksempel med en feil. For å være sikker på at bare én fil ble analysert, la jeg til flagget -r til pvs-studio-dotnet lanseringslinjen:

Vi ser at analysatoren fant en feil og ikke tillot sammenslåing av grener.

La oss sjekke eksemplet uten feil. Korrigering av koden:

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

Slå sammen forespørselsanalyseresultater:

Som vi kan se, ble ingen feil funnet, og oppgavekjøringen var vellykket, noe vi ønsket å sjekke.

Konklusjon

Å luke ut dårlig kode før du slår sammen grener er veldig praktisk og hyggelig. Så hvis du bruker CI/CD, prøv å bygge inn en statisk analysator for å sjekke. Dessuten gjøres dette ganske enkelt.

Takk for oppmerksomheten.

Hvis du vil dele denne artikkelen med et engelsktalende publikum, vennligst bruk oversettelseslenken: Nikolay Mironov. Analyse av sammenslåingsforespørsler i GitLab ved bruk av PVS-Studio for C#.

Kilde: www.habr.com