Älskar GitLab och hatar buggar? Vill du förbättra kvaliteten på din källkod? Då har du kommit rätt. Idag kommer vi att berätta hur du konfigurerar PVS-Studio C#-analysatorn för att kontrollera sammanslagningsförfrågningar. Ha ett enhörningshumör och trevlig läsning till alla.
Förresten, vi släppte PVS-Studio 7.08, där vi gjorde många saker
- C#-analysator för Linux och macOS;
- plugin för Rider;
- ny fillista kontrollläge.
Kontrollläge för fillistan
Tidigare, för att kontrollera vissa filer, var det nödvändigt att skicka en .xml med en lista över filer till analysatorn. Men eftersom detta inte är särskilt bekvämt har vi lagt till möjligheten att överföra .txt, vilket gör livet väldigt enkelt.
För att kontrollera specifika filer måste du ange flaggan --sourceFiles (-f) och överför .txt med en lista över filer. Det ser ut så här:
pvs-studio-dotnet -t path/to/solution.sln -f fileList.txt -o project.json
Om du är intresserad av att ställa in commit-kontroll eller pull-förfrågningar kan du också göra det med det här läget. Skillnaden kommer att vara att få en lista över filer att analysera och beror på vilka system du använder.
Principen för att kontrollera en sammanslagningsförfrågan
Huvudessensen av kontrollen är att säkerställa att problem som upptäcks av analysatorn under sammanslagning inte faller in i Master gren. Vi vill inte heller analysera hela projektet varje gång. Dessutom, när vi slår samman grenar, har vi en lista över ändrade filer. Därför föreslår jag att du lägger till en kontroll av sammanslagningsförfrågan.
Så här ser en sammanslagningsförfrågan ut innan en statisk analysator implementeras:
Det vill säga alla fel som fanns i grenen förändringar, kommer att flyttas till huvudgrenen. Eftersom vi inte vill ha detta lägger vi till analys och nu ser diagrammet ut så här:
Analyserar ändringar 2 och om det inte finns några fel accepterar vi sammanslagningsbegäran, annars avvisar vi den.
Förresten, om du är intresserad av att analysera commits och pull-förfrågningar för C/C++, då kan du läsa om det
GitLab
Innan du börjar analysera sammanslagningsförfrågningar måste du registrera dig och ladda upp ditt projekt. Om du inte vet hur man gör detta, då föreslår jag
Notera. Metoden för att ställa in miljön som beskrivs nedan är en av de möjliga. Målet är att visa stegen för att ställa in den miljö som krävs för analys och lansering av analysatorn. Kanske i ditt fall skulle det vara mer optimalt att separera stadierna av miljöförberedelse (lägga till förråd, installera en analysator) och analys: till exempel förbereda Docker-bilder med den nödvändiga miljön och använda dem, eller någon annan metod.
För att bättre förstå vad som kommer att hända nu föreslår jag att du tittar på följande diagram:
Analysatorn kräver .NET Core SDK 3 för att fungera, så innan du installerar analysatorn måste du lägga till Microsoft-repositories från vilka de beroenden som krävs för analysatorn kommer att installeras. Lägga till Microsoft-arkiv för olika Linux-distributioner
För att installera PVS-Studio genom pakethanteraren måste du också lägga till PVS-Studio-förråden. Att lägga till repositories för olika distributioner beskrivs mer i detalj i
Analysatorn kräver en licensnyckel för att fungera. Du kan få en provlicens på
Notera. Observera att det beskrivna driftsättet (analys av sammanslagningsförfrågningar) kräver en Enterprise-licens. Därför, om du vill prova detta driftsätt, glöm inte att ange i fältet "Meddelande" att du behöver en Enterprise-licens.
Om en sammanfogningsförfrågan inträffar behöver vi bara analysera listan med ändrade filer, annars analyserar vi alla filer. Efter analys måste vi konvertera loggarna till det format vi behöver.
Nu, med algoritmen för arbete framför dina ögon, kan du gå vidare till att skriva ett manus. För att göra detta måste du ändra filen .gitlab-ci.yml eller, om det inte finns, skapa det. För att skapa det måste du klicka på namnet på ditt projekt -> Ställ in CI/CD.
Nu är vi redo att skriva manuset. Låt oss först skriva koden som ska installera analysatorn och ange 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
Eftersom installation och aktivering måste ske före alla andra skript använder vi en speciell etikett före_script. Låt mig förklara detta fragment lite.
Förbereder installation av analysatorn:
- 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
Lägga till PVS-Studio-förråd och 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
Licensaktivering:
- pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY
$PVS_NAME - Användarnamn.
$PVS_KEY - produktnyckel.
Återställa projektberoenden var $CI_PROJECT_DIR – fullständig sökväg till projektkatalogen:
- dotnet restore "$CI_PROJECT_DIR"/Path/To/Solution.sln
För korrekt analys måste projektet byggas framgångsrikt och dess beroenden måste återställas (till exempel måste de nödvändiga NuGet-paketen laddas ner).
Du kan ställa in miljövariabler som innehåller licensinformation genom att klicka Att lägga plattor, och efteråt CI/CD.
Hitta objektet i fönstret som öppnas variabler, klicka på knappen till höger Bygga ut och lägg till variabler. Resultatet ska se ut så här:
Nu kan du gå vidare till analys. Låt oss först lägga till ett skript för en fullständig analys. Till flaggan -t vi passerar vägen till lösningen på flaggan -o skriv sökvägen till filen där analysresultaten ska skrivas. Vi är också intresserade av returkoden. I det här fallet är vi intresserade av att operationen stoppas när returkoden innehåller information om att varningar har utfärdats under analysen. Så här ser det här 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 fungerar enligt principen om en bitmask. Till exempel, om varningar utfärdades som ett resultat av analysen, kommer returkoden att vara lika med 8. Om licensen löper ut inom en månad kommer returkoden att vara lika med 4. Om fel upptäcktes under analysen, och licensen löper ut inom en månad, koden returnerar, båda värdena kommer att skrivas: lägg ihop siffrorna och få den slutliga returkoden - 8+4=12. Genom att kontrollera motsvarande bitar kan således information om olika tillstånd erhållas under analys. Returkoder beskrivs mer i detalj i avsnittet "pvs-studio-dotnet (Linux / macOS) returkoder" i dokumentet "
I det här fallet är vi intresserade av alla returkoder där 8 visas.
- exit_code=$((($exit_code & 8)/8))
Vi får 1 när returkoden innehåller biten av numret vi är intresserade av, annars får vi 0.
Det är dags att lägga till analys av sammanslagningsförfrågningar. Innan vi gör detta, låt oss förbereda en plats för manuset. Vi behöver bara köra det när en sammanslagningsbegäran inträffar. Det ser ut så här:
merge:
script:
only:
- merge_requests
Låt oss gå vidare till själva manuset. Jag stod inför det faktum att den virtuella maskinen inte vet något om ursprung / mästare. Så låt oss hjälpa henne lite:
- git fetch origin
Nu får vi skillnaden mellan grenarna och sparar resultatet in Text fil:
- git diff --name-only origin/master $CI_COMMIT_SHA > pvs-fl.txt
var $CI_COMMIT_SHA – hash av den senaste commit.
Därefter börjar vi analysera listan över filer med flaggan -f. Vi överför den tidigare mottagna .txt-filen till den. Tja, analogt med den fullständiga analysen tittar vi på returkoderna:
- 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 fullständiga skriptet för att kontrollera en sammanslagningsförfrågan kommer att se ut så här:
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
Allt som återstår är att lägga till loggkonvertering efter att alla skript har bearbetats. Vi använder etiketten efter_skript och nytta plog-omvandlare:
after_script:
- plog-converter -t html -o eLog ./PVS-Studio.json
Verktyg
Förresten, om du bekvämt vill arbeta med .json-rapporter lokalt från IDE, så föreslår jag vår
För enkelhetens skull, här är 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 till allt i filen klickar du på Begå ändringar. För att se att allt är korrekt, gå till CI / CD -> Rörledningar -> Springa. Ett virtuellt maskinfönster öppnas, i slutet av vilket det bör finnas följande:
fick syn på Job lyckades - framgång, allt är bra. Nu kan du testa vad du har gjort.
Exempel på arbete
För ett exempel på arbete, låt oss skapa ett enkelt projekt (i Master) som kommer att innehålla flera filer. Efter det, i en annan gren kommer vi bara att ändra en fil och försöka göra en sammanfogningsförfrågan.
Låt oss överväga två fall: när den ändrade filen innehåller ett fel och när den inte gör det. Först ett exempel med ett fel.
Låt oss säga att det finns en fil i mastergrenen Program.cs, som inte innehåller fel, men i en annan gren har utvecklaren lagt till felaktig kod och vill göra en sammanslagningsförfrågan. Vilken typ av misstag han gjorde är inte så viktigt, huvudsaken är att det finns. Till exempel glömde operatören kasta (Ja,
void MyAwesomeMethod(String name)
{
if (name == null)
new ArgumentNullException(....);
// do something
....
}
Låt oss titta på resultatet av att analysera ett exempel med ett fel. För att vara säker på att bara en fil analyserades lade jag till flaggan -r till pvs-studio-dotnet lanseringslinje:
Vi ser att analysatorn hittade ett fel och inte tillät sammanslagning av grenar.
Låt oss kolla exemplet utan fel. Korrigera koden:
void MyAwesomeMethod(String name)
{
if (name == null)
throw new ArgumentNullException(....);
// do something
....
}
Sammanfoga resultat för begäran om analys:
Som vi kan se hittades inga fel, och uppgiftsexekveringen lyckades, vilket är vad vi ville kontrollera.
Slutsats
Att rensa bort dålig kod innan man slår ihop grenar är väldigt bekvämt och trevligt. Så om du använder CI/CD, försök att bädda in en statisk analysator för att kontrollera. Dessutom görs detta helt enkelt.
Tack för er uppmärksamhet.
Om du vill dela den här artikeln med en engelsktalande publik, använd gärna översättningslänken: Nikolay Mironov.
Källa: will.com