Analyse van samenvoegverzoeken in GitLab met behulp van PVS-Studio voor C#

Houd je van GitLab en heb je een hekel aan bugs? Wilt u de kwaliteit van uw broncode verbeteren? Dan bent u bij ons aan het juiste adres. Vandaag vertellen we u hoe u de PVS-Studio C#-analysator configureert om samenvoegverzoeken te controleren. Heb een eenhoornstemming en veel leesplezier voor iedereen.

PVS Studio is een hulpmiddel voor het identificeren van fouten en potentiële kwetsbaarheden in de broncode van programma's geschreven in C, C++, C# en Java. Werkt op 64-bit systemen op Windows, Linux en macOS. Kan code analyseren die is ontworpen voor 32-bits, 64-bits en embedded ARM-platforms.

We hebben trouwens PVS-Studio 7.08 uitgebracht, waarin we veel dingen hebben gedaan interessant. Bijvoorbeeld:

• C#-analysator voor Linux en macOS;
• plug-in voor Ruiter;
• nieuwe controlemodus voor de bestandslijst.

Controlemodus voor bestandslijst

Voorheen was het, om bepaalde bestanden te controleren, nodig om een ​​.xml-bestand met een lijst met bestanden door te geven aan de analysator. Maar omdat dit niet erg handig is, hebben we de mogelijkheid toegevoegd om .txt over te zetten, wat het leven heel eenvoudig maakt.

Om specifieke bestanden te controleren, moet u de vlag opgeven --bronbestanden (-f) en breng .txt over met een lijst met bestanden. Het ziet er zo uit:

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

Als je geïnteresseerd bent in het instellen van commit-controle of pull-aanvragen, kun je dat ook doen in deze modus. Het verschil zit hem in het verkrijgen van een lijst met te analyseren bestanden en hangt af van de systemen die u gebruikt.

Het principe van het controleren van een samenvoegverzoek

De belangrijkste essentie van de controle is om ervoor te zorgen dat problemen die door de analysator tijdens het samenvoegen worden gedetecteerd, niet in de problemen vallen meester tak. We willen ook niet elke keer het hele project analyseren. Bovendien hebben we bij het samenvoegen van takken een lijst met gewijzigde bestanden. Daarom stel ik voor een controle op samenvoegverzoeken toe te voegen.

Zo ziet een samenvoegverzoek eruit voordat een statische analysator wordt geïmplementeerd:

Dat wil zeggen, alle fouten die in de branche aanwezig waren veranderingen, zal naar de master branch gaan. Omdat we dit niet zouden willen, voegen we analyse toe, en nu ziet het diagram er als volgt uit:

Analyseren veranderingen2 en als er geen fouten zijn, accepteren we het samenvoegverzoek, anders wijzen we het af.

Trouwens, als je geïnteresseerd bent in het analyseren van commits en pull-requests voor C/C++, dan kun je erover lezen hier.

GitLab

GitLab is een open source webgebaseerde DevOps-levenscyclustool die een coderepositorybeheersysteem voor Git biedt met een eigen wiki, probleemvolgsysteem, CI/CD-pijplijn en andere functies.

Voordat u samenvoegverzoeken gaat analyseren, moet u uw project registreren en uploaden. Als je niet weet hoe je dit moet doen, raad ik je aan het te doen статью mijn collega.

Noot. De hieronder beschreven werkwijze voor het inrichten van de omgeving behoort tot de mogelijke mogelijkheden. Het doel is om de stappen te tonen voor het opzetten van de omgeving die nodig is voor analyse en het starten van de analysator. Misschien zou het in uw geval optimaal zijn om de fasen van omgevingsvoorbereiding (opslagplaatsen toevoegen, een analysator installeren) en analyse te scheiden: bijvoorbeeld het voorbereiden van Docker-images met de benodigde omgeving en het gebruik ervan, of een andere methode.

Om beter te begrijpen wat er nu zal gebeuren, stel ik voor om naar het volgende diagram te kijken:

De analyser heeft .NET Core SDK 3 nodig om te kunnen werken, dus voordat u de analyser installeert, moet u de Microsoft-opslagplaatsen toevoegen van waaruit de afhankelijkheden die vereist zijn voor de analyser worden geïnstalleerd. Microsoft-opslagplaatsen toevoegen voor verschillende Linux-distributies beschreven in het bijbehorende document.

Om PVS-Studio via de pakketbeheerder te installeren, moet u ook de PVS-Studio-repository's toevoegen. Het toevoegen van repository's voor verschillende distributies wordt gedetailleerder beschreven in relevante sectie van de documentatie.

De analysator heeft een licentiesleutel nodig om te kunnen werken. U kunt een proeflicentie verkrijgen op downloadpagina voor analysator.

Noot. Houd er rekening mee dat voor de beschreven werking (analyse van samenvoegverzoeken) een Enterprise-licentie vereist is. Als u deze werkingsmodus wilt proberen, vergeet dan niet om in het veld 'Bericht' aan te geven dat u een Enterprise-licentie nodig heeft.

Als er een samenvoegverzoek plaatsvindt, hoeven we alleen de lijst met gewijzigde bestanden te analyseren, anders analyseren we alle bestanden. Na analyse moeten we de logs converteren naar het formaat dat we nodig hebben.

Nu u het algoritme van het werk voor ogen heeft, kunt u doorgaan met het schrijven van een script. Om dit te doen, moet u het bestand wijzigen .gitlab-ci.yml of, als het niet bestaat, maak het dan aan. Om het te maken, moet u op de naam van uw project klikken -> CI/CD instellen.

Nu zijn we klaar om het script te schrijven. Laten we eerst de code schrijven waarmee de analysator wordt geïnstalleerd en de licentie wordt ingevoerd:

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

Omdat installatie en activering vóór alle andere scripts moeten plaatsvinden, gebruiken we een speciaal label voor_script. Laat me dit fragment een beetje toelichten.

Voorbereiden om de analysator te installeren:

  - 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

PVS-Studio-repository's en analyser toevoegen:

  - 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

Licentie activatie:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME - Gebruikersnaam.

$PVS_KEY - product sleutel.

Projectafhankelijkheden herstellen waar $CI_PROJECT_DIR – volledig pad naar de projectmap:

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

Voor een correcte analyse moet het project met succes worden gebouwd en moeten de afhankelijkheden ervan worden hersteld (de benodigde NuGet-pakketten moeten bijvoorbeeld worden gedownload).

U kunt omgevingsvariabelen met licentie-informatie instellen door op te klikken omgeving, en na - op CI/CD.

Zoek het item in het venster dat wordt geopend Variabelen, klik op de knop aan de rechterkant Uitvouwen en variabelen toevoegen. Het resultaat zou er als volgt uit moeten zien:

Nu kunt u verdergaan met de analyse. Laten we eerst een script toevoegen voor een volledige analyse. Naar de vlag -t we passeren het pad naar de oplossing voor de vlag -o schrijf het pad naar het bestand waarin de analyseresultaten zullen worden geschreven. Wij zijn ook geïnteresseerd in de retourcode. In dit geval zijn we geïnteresseerd in het stoppen van de bewerking wanneer de retourcode informatie bevat dat er tijdens de analyse waarschuwingen zijn afgegeven. Zo ziet dit fragment eruit:

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

Returncodes werken volgens het principe van een bitmasker. Als er bijvoorbeeld naar aanleiding van de analyse waarschuwingen zijn afgegeven, is de retourcode gelijk aan 8. Als de licentie binnen een maand afloopt, is de retourcode gelijk aan 4. Als er tijdens de analyse fouten zijn geconstateerd, en de licentie verloopt binnen een maand, de code retourneert, beide waarden worden geschreven: tel de cijfers bij elkaar op en verkrijg de uiteindelijke retourcode - 8+4=12. Door de overeenkomstige bits te controleren, kan dus tijdens de analyse informatie over verschillende toestanden worden verkregen. Retourcodes worden gedetailleerder beschreven in de sectie "pvs-studio-dotnet (Linux / macOS) Return Codes" van het document "Visual Studio / MSBuild / .NET Core-projecten controleren vanaf de opdrachtregel met behulp van PVS-Studio".

In dit geval zijn we geïnteresseerd in alle retourcodes waar 8 verschijnt.

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

We ontvangen een 1 als de retourcode het bit bevat van het nummer waarin we geïnteresseerd zijn, anders ontvangen we een 0.

Het is tijd om analyse van samenvoegverzoeken toe te voegen. Voordat we dit doen, moeten we een plaats voor het script voorbereiden. We willen dat het alleen wordt uitgevoerd als er een samenvoegverzoek plaatsvindt. Het ziet er zo uit:

merge:
  script:
  only:
  - merge_requests

Laten we verder gaan met het script zelf. Ik werd geconfronteerd met het feit dat de virtuele machine er niets van weet herkomst/meester. Dus laten we haar een beetje helpen:

  - git fetch origin

Nu krijgen we het verschil tussen de takken en slaan we het resultaat op txt bestand:

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

Где $CI_COMMIT_SHA – hash van de laatste commit.

Vervolgens beginnen we met het analyseren van de lijst met bestanden met behulp van de vlag -f. Wij zetten het eerder ontvangen .txt-bestand ernaar over. Welnu, naar analogie van de volledige analyse kijken we naar de retourcodes:

  - 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

Het volledige script voor het controleren van een samenvoegverzoek ziet er als volgt uit:

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

Het enige dat overblijft is het toevoegen van logconversie nadat alle scripts zijn verwerkt. Wij gebruiken het etiket na_script en nut plog-converter:

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

Nut plog-converter is een open source-project dat wordt gebruikt om parserfoutrapporten om te zetten in verschillende vormen, zoals HTML. Een meer gedetailleerde beschrijving van het hulpprogramma vindt u in de subsectie "Plog Converter Utility" relevante sectie van de documentatie.

Trouwens, als je gemakkelijk lokaal met .json-rapporten vanuit de IDE wilt werken, dan raad ik onze .json-rapporten aan inpluggen voor IDE Rider. Het gebruik ervan wordt gedetailleerder beschreven in relevant document.

Voor het gemak is het hier .gitlab-ci.yml volledig:

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

Als u alles aan het bestand heeft toegevoegd, klikt u op Wijzigingen vastleggen. Om te zien of alles correct is, gaat u naar CI / CD -> Pijpleidingen -> Hardlopen. Er wordt een venster van een virtuele machine geopend, met aan het einde het volgende:

zaag Het is gelukt - succes, alles is in orde. Nu kun je testen wat je hebt gedaan.

Werkvoorbeelden

Laten we voor een voorbeeld van werk een eenvoudig project maken (in meester) die verschillende bestanden zal bevatten. Daarna zullen we in een andere branch slechts één bestand wijzigen en proberen een samenvoegverzoek in te dienen.

Laten we twee gevallen bekijken: wanneer het gewijzigde bestand een fout bevat en wanneer dat niet het geval is. Eerst een voorbeeld met een fout.

Laten we zeggen dat er een bestand in de masterbranch staat Programma.cs, die geen fouten bevat, maar in een andere branch heeft de ontwikkelaar foutieve code toegevoegd en wil hij een samenvoegverzoek indienen. Wat voor soort fout hij heeft gemaakt, is niet zo belangrijk, het belangrijkste is dat deze bestaat. De telefoniste vergat het bijvoorbeeld Gooi (Ja, zo fout):

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

Laten we eens kijken naar het resultaat van het analyseren van een voorbeeld met een fout. Om er zeker van te zijn dat slechts één bestand werd geparseerd, heb ik de vlag toegevoegd -r naar de pvs-studio-dotnet-lanceringslijn:

We zien dat de analysator een fout heeft gevonden en het samenvoegen van takken niet toestaat.

Laten we het voorbeeld zonder fouten bekijken. De code corrigeren:

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

Analyseresultaten van verzoek samenvoegen:

Zoals we kunnen zien, zijn er geen fouten gevonden en is de taakuitvoering succesvol verlopen, wat we wilden controleren.

Conclusie

Het verwijderen van slechte code vóór het samenvoegen van branches is erg handig en prettig. Dus als u CI/CD gebruikt, probeer dan een statische analysator in te sluiten om dit te controleren. Bovendien gebeurt dit vrij eenvoudig.

Dank u voor uw aandacht.

Als u dit artikel met een Engelssprekend publiek wilt delen, gebruik dan de vertaallink: Nikolay Mironov. Analyse van samenvoegverzoeken in GitLab met behulp van PVS-Studio voor C#.

Bron: www.habr.com