🥇Analizo de kunfandaj petoj en GitLab uzante PVS-Studio por C#

Ĉu vi amas GitLab kaj malamas cimojn? Ĉu vi volas plibonigi la kvaliton de via fontkodo? Tiam vi venis al la ĝusta loko. Hodiaŭ ni rakontos al vi kiel agordi la analizilon PVS-Studio C# por kontroli kunfandajn petojn. Havu unikornan humoron kaj feliĉan legadon al ĉiuj.

PVS Studio estas ilo por identigi erarojn kaj eblajn vundeblecojn en la fontkodo de programoj skribitaj en C, C++, C# kaj Java. Funkcias sur 64-bitaj sistemoj en Vindozo, Linukso kaj macOS. Kapablas analizi kodon dizajnitan por 32-bita, 64-bita kaj enigita ARM-platformoj.

Cetere, ni publikigis PVS-Studio 7.08, en kiu ni faris multajn aferojn interesaj. Ekzemple:

C# analizilo por Linukso kaj macOS;
kromaĵo por Rider;
nova dosierlisto kontrola reĝimo.

Dosiera listo kontrola reĝimo

Antaŭe, por kontroli iujn dosierojn, estis necese transdoni .xml kun listo de dosieroj al la analizilo. Sed ĉar ĉi tio ne estas tre oportuna, ni aldonis la kapablon translokigi .txt, kio faras la vivon tre simpla.

Por kontroli specifajn dosierojn, vi devas specifi la flagon --fontaj dosieroj (-f) kaj translokigu .txt kun listo de dosieroj. Ĝi aspektas jene:

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

Se vi interesiĝas pri agordo de komitkontrolado aŭ tiri petoj, vi ankaŭ povas fari tion uzante ĉi tiun reĝimon. La diferenco estos en ricevi liston de analizendaj dosieroj kaj dependos de kiaj sistemoj vi uzas.

La principo kontroli kunfandan peton

La ĉefa esenco de la ĉeko estas certigi, ke problemoj detektitaj de la analizilo dum kunfandado ne falas en la majstro branĉo. Ni ankaŭ ne volas ĉiufoje analizi la tutan projekton. Plie, dum kunfandado de branĉoj, ni havas liston de ŝanĝitaj dosieroj. Tial mi sugestas aldoni kontrolon pri kunfanda peto.

Jen kiel aspektas kunfanda peto antaŭ ol efektivigi senmovan analizilon:

Tio estas, ĉiuj eraroj, kiuj estis en la branĉo ŝanĝoj, translokiĝos al la majstra branĉo. Ĉar ni ne dezirus ĉi tion, ni aldonas analizon, kaj nun la diagramo aspektas jene:

Ni analizas ŝanĝoj2 kaj, se ne estas eraroj, ni akceptas la kunfandi peton, alie ni malakceptas ĝin.

Cetere, se vi interesiĝas pri analizo de komitaĵoj kaj tiri petojn por C/C++, tiam vi povas legi pri ĝi tie.

GitLab

GitLab estas malfermfonta ret-bazita DevOps-vivciklo-ilo, kiu provizas kodan deponan administradsistemon por Git kun sia propra vikio, temo-spuradsistemo, CI/KD-dukto kaj aliaj funkcioj.

Antaŭ ol vi komencas analizi kunfandpetojn, vi devas registri kaj alŝuti vian projekton. Se vi ne scias kiel fari tion, tiam mi sugestas artikolo mia kolego.

Примечание. La metodo de agordo de la medio priskribita sube estas unu el la eblaj. La celo estas montri la paŝojn por starigi la medion necesan por analizo kaj lanĉi la analizilon. Eble en via kazo estus pli optimuma apartigi la etapoj de mediopreparo (aldono de deponejoj, instalo de analizilo) kaj analizo: ekzemple, prepari Docker-bildojn kun la necesa medio kaj uzi ilin, aŭ iun alian metodon.

Por pli bone kompreni, kio okazos nun, mi sugestas rigardi la sekvan diagramon:

La analizilo postulas .NET Core SDK 3 por funkcii, do antaŭ ol instali la analizilon vi devas aldoni la Microsoft-deponejojn el kiuj la dependecoj necesaj por la analizilo estos instalitaj. Aldonante Microsoft-deponejojn por diversaj Linuksaj distribuoj priskribita en la responda dokumento.

Por instali PVS-Studio per la pakadministranto, vi ankaŭ devos aldoni la deponejojn de PVS-Studio. Aldono de deponejoj por malsamaj distribuoj estas priskribita pli detale en koncerna sekcio de la dokumentaro.

La analizilo postulas permesilon ŝlosilon por funkcii. Vi povas akiri provan permesilon ĉe analizilo elŝuta paĝo.

Примечание. Bonvolu noti, ke la priskribita funkciadmaniero (analizo de kunfandaj petoj) postulas Enterprise-licencon. Tial, se vi volas provi ĉi tiun operacion, ne forgesu indiki en la kampo "Mesaĝo", ke vi bezonas Enterprise-licencon.

Se kunfanda peto okazas, tiam ni nur bezonas analizi la liston de ŝanĝitaj dosieroj, alie ni analizas ĉiujn dosierojn. Post analizo, ni devas konverti la protokolojn en la formaton, kiun ni bezonas.

Nun, havante la algoritmon de laboro antaŭ viaj okuloj, vi povas pluiri al verkado de skripto. Por fari tion, vi devas ŝanĝi la dosieron .gitlab-ci.yml aŭ, se ĝi ne ekzistas, kreu ĝin. Por krei ĝin, vi devas alklaki la nomon de via projekto -> Agordu CI/KD.

Nun ni pretas skribi la skripton. Ni unue skribu la kodon, kiu instalos la analizilon kaj enigu la permesilon:

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

Ĉar instalado kaj aktivigo devas okazi antaŭ ĉiuj aliaj skriptoj, ni uzas specialan etikedon antaŭ_skripto. Mi klarigu ĉi tiun fragmenton iomete.

Preparante instali la analizilon:

  - 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

Aldonante deponejojn kaj analizilon de PVS-Studio:

  - 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

Aktivigo de licenco:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME - Uzantnomo.

$PVS_KEY - produktŝlosilo.

Reakiro de projektaj dependecoj kie $CI_PROJECT_DIR - plena vojo al la projekta dosierujo:

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

Por ĝusta analizo, la projekto devas esti konstruita sukcese, kaj ĝiaj dependecoj devas esti restarigitaj (ekzemple, la necesaj NuGet-pakaĵoj devas esti elŝutitaj).

Vi povas agordi mediajn variablojn enhavantajn licencajn informojn per klako fikso, kaj post - sur CI/KD.

En la fenestro kiu malfermiĝas, trovu la eron variabloj, alklaku la butonon dekstre Ekspansiiĝi kaj aldonu variablojn. La rezulto devus aspekti jene:

Nun vi povas pluiri al analizo. Unue, ni aldonu skripton por kompleta analizo. Al la flago -t ni pasas la vojon al la solvo al la flago -o skribu la vojon al la dosiero en kiu la analizrezultoj estos skribitaj. Ni ankaŭ interesiĝas pri la revenkodo. En ĉi tiu kazo, ni interesas, ke la operacio ĉesos kiam la revenkodo enhavas informojn, ke avertoj estis eligitaj dum la analizo. Jen kiel aspektas ĉi tiu fragmento:

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

Revenkodoj funkcias laŭ la principo de bita masko. Ekzemple, se avertoj estis elsenditaj kiel rezulto de la analizo, tiam la revenkodo estos egala al 8. Se la permesilo eksvalidiĝas ene de monato, tiam la revenkodo estos egala al 4. Se eraroj estis detektitaj dum la analizo, kaj la permesilo eksvalidiĝas ene de monato, la kodo revenas, ambaŭ valoroj estos skribitaj: aldonu la nombrojn kune kaj ricevu la finan revenkodon - 8+4=12. Tiel, kontrolante la respondajn bitojn, informoj pri diversaj statoj povas esti akiritaj dum analizo. Revenkodoj estas priskribitaj pli detale en la sekcio "pvs-studio-dotnet (Linukso / macOS) Revenkodoj" de la dokumento "Kontrolante Visual Studio / MSBuild / .NET Core projektojn de la komandlinio uzante PVS-Studio".

En ĉi tiu kazo, ni interesiĝas pri ĉiuj revenkodoj kie 8 aperas.

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

Ni ricevos 1 kiam la revenkodo enhavas la pecon de la nombro, pri kiu ni interesiĝas, alie ni ricevos 0.

Estas tempo aldoni analizon pri kunfanda peto. Antaŭ ol ni fari tion, ni preparu lokon por la skripto. Ni bezonas, ke ĝi estu ekzekutita nur kiam okazas kunfanda peto. Ĝi aspektas jene:

merge:
  script:
  only:
  - merge_requests

Ni transiru al la skripto mem. Mi alfrontis la fakton, ke la virtuala maŝino nenion scias origino/majstro. Do ni iomete helpu ŝin:

  - git fetch origin

Nun ni ricevas la diferencon inter la branĉoj kaj konservas la rezulton txt dosiero:

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

Kie $CI_COMMIT_SHA – hash de la lasta komito.

Poste, ni komencas analizi la liston de dosieroj uzante la flagon -f. Ni transdonas la antaŭe ricevitan .txt-dosieron al ĝi. Nu, analoge kun la plena analizo, ni rigardas la revenkodojn:

  - 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

La kompleta skripto por kontroli kunfandan peton aspektos jene:

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

Restas nur aldoni protokolan konvertiĝon post kiam ĉiuj skriptoj estis prilaboritaj. Ni uzas la etikedon post_skripto kaj utileco plog-konvertilo:

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

Utileco plog-konvertilo estas malfermfonteca projekto, kiu estas uzata por konverti erarraportojn de analiziloj en diversajn formojn, kiel HTML. Pli detala priskribo de la utileco estas donita en la subsekcio "Plog Converter Utility" koncerna sekcio de la dokumentaro.

Cetere, se vi volas oportune labori kun .json-raportoj loke de la IDE, tiam mi proponas nian kromaĵo por IDE Rider. Ĝia uzo estas priskribita pli detale en koncerna dokumento.

Por komforto, jen ĝi .gitlab-ci.yml plene:

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

Post kiam vi aldonis ĉion al la dosiero, alklaku Faru ŝanĝojn. Por vidi, ke ĉio estas ĝusta, iru al CI / KD -> Duktoj -> kurante. Fenestro de virtuala maŝino malfermos, ĉe kies fino devus esti la jena:

vidis Ijob sukcesis - sukceso, ĉio estas en ordo. Nun vi povas testi tion, kion vi faris.

Ekzemploj de laboro

Por ekzemplo de laboro, ni kreu simplan projekton (en majstro) kiu enhavos plurajn dosierojn. Post tio, en alia branĉo ni ŝanĝos nur unu dosieron kaj provos fari kunfandpeton.

Ni konsideru du kazojn: kiam la modifita dosiero enhavas eraron kaj kiam ĝi ne havas. Unue, ekzemplo kun eraro.

Ni diru, ke estas dosiero en la majstra branĉo Programo.cs, kiu ne enhavas erarojn, sed en alia branĉo la programisto aldonis eraran kodon kaj volas fari kunfandpeton. Kia eraro li faris ne tiom gravas, la ĉefa afero estas, ke ĝi ekzistas. Ekzemple, la operatoro forgesis ĵetu (Jes, tiel malĝuste):

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

Ni rigardu la rezulton de analizo de ekzemplo kun eraro. Ankaŭ por certigi, ke nur unu dosiero estas analizita, mi aldonis la flagon -r al la pvs-studio-dotnet lanĉa linio:

Ni vidas, ke la analizilo trovis eraron kaj ne permesis kunfandi branĉojn.

Ni kontrolu la ekzemplon sen eraro. Korektante la kodon:

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

Kunfandi petajn analizrezultojn:

Kiel ni povas vidi, neniuj eraroj estis trovitaj, kaj la tasko ekzekuto estis sukcesa, kio estas kion ni volis kontroli.

konkludo

Forigi malbonan kodon antaŭ kunfandi branĉojn estas tre oportuna kaj agrabla. Do se vi uzas CI/KD, provu enigi statikan analizilon por kontroli. Krome, ĉi tio estas farita tute simple.

Dankon pro via atento.

Se vi volas dividi ĉi tiun artikolon kun anglalingva publiko, bonvolu uzi la tradukan ligilon: Nikolay Mironov. Analizo de kunfandaj petoj en GitLab uzante PVS-Studio por C#.

fonto: www.habr.com

Analizo de kunfandaj petoj en GitLab uzante PVS-Studio por C#

Dosiera listo kontrola reĝimo

La principo kontroli kunfandan peton

GitLab

Ekzemploj de laboro

konkludo

Aldoni komenton Отменить ответ