Analyse fan fúzjeoanfragen yn GitLab mei PVS-Studio foar C#

Analyse fan fúzjeoanfragen yn GitLab mei PVS-Studio foar C#
Hâld fan GitLab en haat bugs? Wolle jo de kwaliteit fan jo boarnekoade ferbetterje? Dan binne jo op it goede plak kommen. Hjoed sille wy jo fertelle hoe't jo de PVS-Studio C#-analyzer konfigurearje om fúzjeoanfragen te kontrolearjen. Hawwe in ienhoarnstimming en lokkich lêzen foar elkenien.

PVS-Studio is in ark foar it identifisearjen fan flaters en potinsjele kwetsberens yn 'e boarnekoade fan programma's skreaun yn C, C++, C# en Java. Wurket op 64-bit systemen op Windows, Linux en macOS. Kin koade analysearje ûntworpen foar 32-bit, 64-bit en ynbêde ARM-platfoarms.

Trouwens, wy hawwe PVS-Studio 7.08 frijlitten, wêryn wy in protte dingen diene nijsgjirrich. Bygelyks:

  • C # analysator foar Linux en macOS;
  • plugin foar Rider;
  • nije triemlist kontrolearjen modus.

Bestânslist kontrolearjen modus

Earder, om bepaalde triemmen te kontrolearjen, wie it nedich om in .xml mei in list fan triemmen troch te jaan oan de analysator. Mar om't dit net heul handich is, hawwe wy de mooglikheid tafoege om .txt oer te setten, wat it libben heul ienfâldich makket.

Om spesifike triemmen te kontrolearjen, moatte jo de flagge opjaan --sourceFiles (-f) en oerdrage .txt mei in list mei triemmen. It sjocht der sa út:

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

As jo ​​​​ynteressearre binne yn it ynstellen fan commit kontrôle of pull-oanfragen, kinne jo dat ek dwaan mei dizze modus. It ferskil sil wêze yn it krijen fan in list mei bestannen om te analysearjen en sil ôfhingje fan hokker systemen jo brûke.

It prinsipe fan it kontrolearjen fan in fúzjefersyk

De wichtichste essinsje fan de kontrôle is om te soargjen dat problemen ûntdutsen troch de analyzer tidens gearfoeging net falle yn 'e master tûke. Wy wolle ek net elke kear it hiele projekt analysearje. Boppedat hawwe wy by it fusearjen fan tûken in list mei feroare bestannen. Dêrom stel ik foar in fúzjefersykkontrôle ta te foegjen.

Dit is hoe't in fúzjefersyk der útsjocht foardat jo in statyske analysator ymplementearje:

Analyse fan fúzjeoanfragen yn GitLab mei PVS-Studio foar C#
Dat is, alle flaters dy't wiene yn 'e branch feroarings, sil ferhúzje nei de master branch. Om't wy dit net wolle, foegje wy analyse ta, en no sjocht it diagram der sa út:

Analyse fan fúzjeoanfragen yn GitLab mei PVS-Studio foar C#
Wy analysearje feroarings2 en, as der gjin flaters, wy akseptearje it fúzje fersyk, oars wy wegerje it.

Trouwens, as jo ynteressearre binne yn it analysearjen fan ferplichtingen en oanfragen foar C / C ++, dan kinne jo der oer lêze hjir.

GitLab

GitLab is in iepen boarne web-basearre DevOps-libbensyklus-ark dat in koade-repository-behearsysteem foar Git leveret mei in eigen wiki, probleem tracking systeem, CI / CD pipeline en oare funksjes.

Foardat jo begjinne mei it analysearjen fan fúzjeoanfragen, moatte jo jo projekt registrearje en uploade. As jo ​​​​net witte hoe't jo dit dwaan, dan stel ik foar in artikel myn kollega.

remark. De metoade foar it ynstellen fan 'e omjouwing beskreaun hjirûnder is ien fan' e mooglike. It doel is om de stappen te toanen foar it ynstellen fan de omjouwing dy't nedich is foar analyse en it starten fan 'e analysator. Miskien soe it yn jo gefal mear optimaal wêze om de stadia fan omjouwingsfoarming te skieden (tafoeging fan repositories, ynstallearjen fan in analysator) en analyse: bygelyks it tarieden fan Docker-ôfbyldings mei de nedige omjouwing en se brûke, as in oare metoade.

Om better te begripen wat der no sil barre, stel ik foar om nei it folgjende diagram te sjen:

Analyse fan fúzjeoanfragen yn GitLab mei PVS-Studio foar C#
De analysator fereasket .NET Core SDK 3 om te operearjen, dus foardat jo de analysator ynstallearje moatte jo de Microsoft-repositories taheakje wêrfan de ôfhinklikens dy't nedich binne foar de analyzer wurde ynstalleare. It tafoegjen fan Microsoft-repositories foar ferskate Linux-distribúsjes beskreaun yn it byhearrende dokumint.

Om PVS-Studio te ynstallearjen fia de pakketbehearder, moatte jo ek de PVS-Studio-repositories tafoegje. It tafoegjen fan repositories foar ferskate distribúsjes wurdt yn mear detail beskreaun yn relevante seksje fan 'e dokumintaasje.

De analysator fereasket in lisinsjekaai om te operearjen. Jo kinne krije in proef lisinsje by analyzer download side.

remark. Tink derom dat de beskreaune modus fan wurking (analyze fan fúzjeoanfragen) in Enterprise-lisinsje fereasket. Dêrom, as jo dizze modus fan operaasje wolle besykje, ferjit dan net yn it fjild "Berjocht" oan te jaan dat jo in Enterprise-lisinsje nedich binne.

As in fúzjefersyk foarkomt, dan hoege wy allinich de list fan feroare bestannen te analysearjen, oars analysearje wy alle bestannen. Nei analyse moatte wy de logs konvertearje yn it formaat dat wy nedich binne.

No, mei it algoritme fan wurk foar jo eagen, kinne jo trochgean mei it skriuwen fan in skript. Om dit te dwaan, moatte jo de triem feroarje .gitlab-ci.yml of, as it net bestiet, meitsje it. Om it te meitsjen, moatte jo klikke op de namme fan jo projekt -> CI/CD ynstelle.

Analyse fan fúzjeoanfragen yn GitLab mei PVS-Studio foar C#
No binne wy ​​klear om it skript te skriuwen. Litte wy earst de koade skriuwe dy't de analysator sil ynstallearje en de lisinsje ynfiere:

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

Sûnt ynstallaasje en aktivearring moatte foarkomme foardat alle oare skripts, wy brûke in spesjale label foar_skript. Lit my dit fragmint in bytsje útlizze.

Tariede op it ynstallearjen fan de analysator:

  - 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 repositories en analysator tafoegje:

  - 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

Lisinsje aktivearring:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME - Brûkersnamme.

$PVS_KEY - produkt koade.

Recovering projekt ôfhinklikens wêr $CI_PROJECT_DIR - folslein paad nei de projektmap:

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

Foar korrekte analyze moat it projekt mei súkses boud wurde, en de ôfhinklikens moatte wurde werombrocht (bygelyks moatte de nedige NuGet-pakketten wurde ynladen).

Jo kinne omjouwingsfariabelen ynstelle mei lisinsjeynformaasje troch te klikken ynstelling, en nei - op CI/CD.

Analyse fan fúzjeoanfragen yn GitLab mei PVS-Studio foar C#
Sykje it item yn it finster dat iepent Feroarings, klikje op de knop rjochts Expand en tafoegje fariabelen. It resultaat moat der sa útsjen:

Analyse fan fúzjeoanfragen yn GitLab mei PVS-Studio foar C#
No kinne jo trochgean nei analyze. Lit ús earst in skript tafoegje foar in folsleine analyze. Nei de flagge -t wy passe it paad nei de oplossing foar de flagge -o skriuw it paad nei it bestân wêryn de analyseresultaten skreaun wurde. Wy binne ek ynteressearre yn it weromkommen koade. Yn dit gefal binne wy ​​ynteressearre yn 'e operaasje dy't stopet as de weromkommende koade ynformaasje befettet dat warskôgingen waarden útjûn tidens de analyze. Dit is hoe't dit fragmint derút sjocht:

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 koades wurkje op it prinsipe fan in bytsje masker. Bygelyks, as warskôgings waarden útjûn as gefolch fan 'e analyze, dan sil de weromkommende koade gelyk wêze oan 8. As de lisinsje binnen in moanne ferrint, dan sil de weromkearkoade gelyk wêze oan 4. As flaters waarden ûntdutsen tidens de analyze, en de lisinsje ferrint binnen in moanne, de koade komt werom, beide wearden sille wurde skreaun: foegje de nûmers byinoar en krije de definitive weromkoade - 8+4=12. Sa, troch it kontrolearjen fan de korrespondearjende bits, kinne ynformaasje oer ferskate steaten wurde krigen tidens analyze. Retourkoades wurde yn mear detail beskreaun yn 'e seksje "pvs-studio-dotnet (Linux / macOS) Return Codes" fan it dokumint "Kontrolearje Visual Studio / MSBuild / .NET Core-projekten fanút de kommandorigel mei PVS-Studio".

Yn dit gefal, wy binne ynteressearre yn alle werom koades dêr't 8 ferskynt.

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

Wy krije 1 as de weromkommende koade it bit fan it nûmer befettet wêryn wy ynteressearre binne, oars krije wy 0.

It is tiid om analyse fan fúzjefersyk ta te foegjen. Foardat wy dit dogge, litte wy in plak foar it skript tariede. Wy moatte it allinich útfiere as in fúzjefersyk optreedt. It sjocht der sa út:

merge:
  script:
  only:
  - merge_requests

Lit ús gean nei it skript sels. Ik waard konfrontearre mei it feit dat de firtuele masine wit neat oer oarsprong / master. Litte wy har dus in bytsje helpe:

  - git fetch origin

No krije wy it ferskil tusken de tûken en bewarje it resultaat yn txt map:

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

Wêr $CI_COMMIT_SHA - hash fan 'e lêste commit.

Dêrnei begjinne wy ​​​​de list mei bestannen te analysearjen mei de flagge -f. Wy drage it earder ûntfongen .txt-bestân oer nei it. No, nei analogy mei de folsleine analyze, sjogge wy nei de weromkommende koades:

  - 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

It folsleine skript foar it kontrolearjen fan in fúzjefersyk sil der sa útsjen:

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

Alles wat oerbliuwt is om logkonverzje ta te foegjen neidat alle skripts binne ferwurke. Wy brûke it label after_script en nut plog-konverter:

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

Utility plog-konverter is in iepen boarne projekt dat wurdt brûkt om parser flater rapporten te konvertearjen yn ferskate foarmen, lykas HTML. In mear detaillearre beskriuwing fan it nut wurdt jûn yn 'e subseksje "Plog Converter Utility" relevante seksje fan 'e dokumintaasje.

Trouwens, as jo maklik wurkje wolle mei .json-rapporten lokaal fan 'e IDE, dan stel ik ús foar ynstekke foar IDE Rider. It gebrûk wurdt beskreaun yn mear detail yn relevante dokumint.

Foar gemak, hjir is it .gitlab-ci.yml hielendal:

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

Sadree't jo hawwe tafoege alles oan de triem, klik op Feroarings ynsette. Om te sjen dat alles korrekt is, gean nei CI / CD -> Pipelines -> Te rinnen. In firtuele masine-finster sil iepenje, oan 'e ein wêrfan it folgjende moat wêze:

Analyse fan fúzjeoanfragen yn GitLab mei PVS-Studio foar C#
sjo Job slagge - sukses, alles is goed. No kinne jo testen wat jo dien hawwe.

Wurk foarbylden

Foar in foarbyld fan wurk, litte wy in ienfâldich projekt meitsje (yn master) dy't ferskate bestannen sille befetsje. Dêrnei sille wy yn in oare branch mar ien bestân feroarje en besykje in fúzjefersyk te meitsjen.

Litte wy twa gefallen beskôgje: as it wizige bestân in flater befettet en wannear net. Earst in foarbyld mei in flater.

Litte wy sizze dat d'r in bestân is yn 'e mastertûke Program.cs, dy't gjin flaters befettet, mar yn in oare branch hat de ûntwikkelder in ferkearde koade tafoege en wol in fúzjefersyk dwaan. Wat foar flater hy makke is net sa wichtich, it wichtichste is dat it bestiet. Bygelyks, de operator fergeat goaie (Ja, sa ferkeard):

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

Litte wy nei it resultaat sjen fan it analysearjen fan in foarbyld mei in flater. Ek om der wis fan te wêzen dat mar ien triem waard parseard, haw ik de flagge tafoege -r nei de lansearringline fan pvs-studio-dotnet:

Analyse fan fúzjeoanfragen yn GitLab mei PVS-Studio foar C#
Wy sjogge dat de analysator in flater fûn en gjin tûken fusearje liet.

Litte wy it foarbyld kontrolearje sûnder in flater. Koade korrigearje:

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

Resultaten fan fersykanalyse gearfoegje:

Analyse fan fúzjeoanfragen yn GitLab mei PVS-Studio foar C#
Sa't wy sjen kinne, waarden gjin flaters fûn, en de útfiering fan 'e taak wie suksesfol, dat is wat wy wolle kontrolearje.

konklúzje

It ûnkrûdjen fan minne koade foardat tûken fusearje is heul handich en noflik. Dus as jo CI / CD brûke, besykje dan in statyske analysator yn te setten om te kontrolearjen. Boppedat wurdt dit frij simpel dien.

Tige tank foar jo oandacht.

Analyse fan fúzjeoanfragen yn GitLab mei PVS-Studio foar C#
As jo ​​​​dit artikel wolle diele mei in Ingelsktalig publyk, brûk dan de oersettingskeppeling: Nikolay Mironov. Analyse fan fúzjeoanfragen yn GitLab mei PVS-Studio foar C#.

Boarne: www.habr.com

Add a comment