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.
Trouwens, wy hawwe PVS-Studio 7.08 frijlitten, wêryn wy in protte dingen diene
- 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:
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:
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
GitLab
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
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:
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
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
De analysator fereasket in lisinsjekaai om te operearjen. Jo kinne krije in proef lisinsje by
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.
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.
Sykje it item yn it finster dat iepent Feroarings, klikje op de knop rjochts Expand en tafoegje fariabelen. It resultaat moat der sa útsjen:
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 "
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
Trouwens, as jo maklik wurkje wolle mei .json-rapporten lokaal fan 'e IDE, dan stel ik ús foar
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:
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,
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:
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:
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.
As jo dit artikel wolle diele mei in Ingelsktalig publyk, brûk dan de oersettingskeppeling: Nikolay Mironov.
Boarne: www.habr.com