Pagsusuri ng mga kahilingan sa pagsasama sa GitLab gamit ang PVS-Studio para sa C#

Mahilig sa GitLab at mapoot sa mga bug? Gusto mong pagbutihin ang kalidad ng iyong source code? Pagkatapos ay dumating ka sa tamang lugar. Ngayon sasabihin namin sa iyo kung paano i-configure ang PVS-Studio C# analyzer upang suriin ang mga kahilingan sa pagsasama. Magkaroon ng unicorn mood at maligayang pagbabasa sa lahat.

PVS-Studio ay isang tool para sa pagtukoy ng mga error at potensyal na kahinaan sa source code ng mga program na nakasulat sa C, C++, C# at Java. Gumagana sa 64-bit system sa Windows, Linux at macOS. Maaaring suriin ang code na idinisenyo para sa 32-bit, 64-bit at naka-embed na ARM platform.

Sa pamamagitan ng paraan, inilabas namin ang PVS-Studio 7.08, kung saan marami kaming ginawa kawili-wili. Halimbawa:

• C# analyzer para sa Linux at macOS;
• plugin para sa Rider;
• bagong file list checking mode.

Mode ng pagsusuri sa listahan ng file

Dati, para masuri ang ilang partikular na file, kailangang magpasa ng .xml na may listahan ng mga file sa analyzer. Ngunit dahil hindi ito masyadong maginhawa, nagdagdag kami ng kakayahang maglipat ng .txt, na ginagawang napakasimple ng buhay.

Upang masuri ang mga partikular na file, dapat mong tukuyin ang bandila --sourceFiles (-f) at ilipat ang .txt na may listahan ng mga file. Mukhang ganito:

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

Kung interesado kang mag-set up ng commit checking o pull request, magagawa mo rin iyon gamit ang mode na ito. Ang pagkakaiba ay nasa pagkuha ng listahan ng mga file na susuriin at depende sa kung anong mga sistema ang iyong ginagamit.

Ang prinsipyo ng pagsuri sa isang kahilingan sa pagsasama

Ang pangunahing kakanyahan ng tseke ay upang matiyak na ang mga problema na nakita ng analyzer sa panahon ng pagsasama ay hindi nahuhulog sa panginoon sangay. Hindi rin namin gustong suriin ang buong proyekto sa bawat oras. Bukod dito, kapag pinagsasama ang mga sangay, mayroon kaming listahan ng mga binagong file. Samakatuwid, iminumungkahi ko ang pagdaragdag ng isang merge request check.

Ito ang hitsura ng isang kahilingan sa pagsasanib bago magpatupad ng isang static na analyzer:

Ibig sabihin, lahat ng mga error na nasa branch mga pagbabago, lilipat sa master branch. Dahil hindi namin ito gusto, nagdaragdag kami ng pagsusuri, at ngayon ang diagram ay ganito ang hitsura:

Pagsusuri mga pagbabago2 at, kung walang mga error, tinatanggap namin ang kahilingan sa pagsasama, kung hindi, tinatanggihan namin ito.

Siyanga pala, kung interesado kang mag-analyze ng mga commit at pull request para sa C/C++, maaari mong basahin ang tungkol dito dito.

GitLab

GitLab ay isang open source na web-based na DevOps lifecycle tool na nagbibigay ng code repository management system para sa Git na may sarili nitong wiki, issue tracking system, CI/CD pipeline at iba pang feature.

Bago mo simulan ang pagsusuri ng mga kahilingan sa pagsasanib, kailangan mong irehistro at i-upload ang iyong proyekto. Kung hindi mo alam kung paano gawin ito, iminumungkahi ko isang artikulo kasamahan ko.

Nota. Ang paraan ng pag-set up ng kapaligirang inilarawan sa ibaba ay isa sa mga posibleng. Ang layunin ay ipakita ang mga hakbang para sa pag-set up ng kapaligiran na kinakailangan para sa pagsusuri at paglulunsad ng analyzer. Marahil sa iyong kaso ay magiging mas pinakamainam na paghiwalayin ang mga yugto ng paghahanda sa kapaligiran (pagdaragdag ng mga repositoryo, pag-install ng analyzer) at pagsusuri: halimbawa, paghahanda ng mga imahe ng Docker na may kinakailangang kapaligiran at paggamit ng mga ito, o ilang iba pang paraan.

Upang mas maunawaan kung ano ang mangyayari ngayon, iminumungkahi kong tingnan ang sumusunod na diagram:

Ang analyzer ay nangangailangan ng .NET Core SDK 3 upang gumana, kaya bago i-install ang analyzer kailangan mong idagdag ang mga Microsoft repository kung saan mai-install ang mga dependency na kinakailangan para sa analyzer. Pagdaragdag ng mga repositoryo ng Microsoft para sa iba't ibang distribusyon ng Linux inilarawan sa kaukulang dokumento.

Upang mai-install ang PVS-Studio sa pamamagitan ng manager ng package, kakailanganin mo ring idagdag ang mga repositoryo ng PVS-Studio. Ang pagdaragdag ng mga repository para sa iba't ibang mga distribusyon ay inilarawan nang mas detalyado sa kaugnay na seksyon ng dokumentasyon.

Ang analyzer ay nangangailangan ng isang susi ng lisensya upang gumana. Maaari kang makakuha ng lisensya sa pagsubok sa pahina ng pag-download ng analyzer.

Nota. Pakitandaan na ang inilarawang mode ng pagpapatakbo (pagsusuri ng mga kahilingan sa pagsasanib) ay nangangailangan ng lisensya ng Enterprise. Samakatuwid, kung nais mong subukan ang mode ng pagpapatakbo na ito, huwag kalimutang ipahiwatig sa field na "Mensahe" na kailangan mo ng lisensya ng Enterprise.

Kung mangyari ang isang kahilingan sa pagsasanib, kailangan lang naming suriin ang listahan ng mga binagong file, kung hindi, sinusuri namin ang lahat ng mga file. Pagkatapos ng pagsusuri, kailangan naming i-convert ang mga log sa format na kailangan namin.

Ngayon, ang pagkakaroon ng algorithm ng trabaho bago ang iyong mga mata, maaari kang magpatuloy sa pagsulat ng isang script. Upang gawin ito, kailangan mong baguhin ang file .gitlab-ci.yml o, kung wala ito, likhain ito. Upang malikha ito, kailangan mong mag-click sa pangalan ng iyong proyekto -> I-set up ang CI/CD.

Ngayon ay handa na kaming isulat ang script. Isulat muna natin ang code na mag-i-install ng analyzer at ipasok ang lisensya:

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

Dahil ang pag-install at pag-activate ay dapat mangyari bago ang lahat ng iba pang mga script, gumagamit kami ng isang espesyal na label before_script. Hayaan akong ipaliwanag nang kaunti ang fragment na ito.

Paghahanda sa pag-install ng analyzer:

  - 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

Pagdaragdag ng mga repositoryo at analyzer ng 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

Pag-activate ng lisensya:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME - Username.

$PVS_KEY - susi ng produkto.

Pagbawi ng mga dependency ng proyekto kung saan $CI_PROJECT_DIR – buong landas sa direktoryo ng proyekto:

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

Para sa tamang pagsusuri, dapat na matagumpay na maitayo ang proyekto, at dapat na maibalik ang mga dependency nito (halimbawa, ang mga kinakailangang pakete ng NuGet ay dapat na ma-download).

Maaari kang magtakda ng mga variable ng kapaligiran na naglalaman ng impormasyon ng lisensya sa pamamagitan ng pag-click Pagtatakda ng, at pagkatapos - sa CI/CD.

Sa window na bubukas, hanapin ang item Variable, i-click ang button sa kanan Lumawak at magdagdag ng mga variable. Ang resulta ay dapat magmukhang ganito:

Ngayon ay maaari kang magpatuloy sa pagsusuri. Una, magdagdag tayo ng script para sa kumpletong pagsusuri. Sa bandila -t pumasa tayo sa landas patungo sa solusyon sa watawat -o isulat ang landas sa file kung saan isusulat ang mga resulta ng pagsusuri. Interesado din kami sa return code. Sa kasong ito, interesado kami sa paghinto ng operasyon kapag ang return code ay naglalaman ng impormasyon na ang mga babala ay ibinigay sa panahon ng pagsusuri. Ganito ang hitsura ng fragment na ito:

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

Gumagana ang mga return code sa prinsipyo ng medyo mask. Halimbawa, kung ang mga babala ay ibinigay bilang resulta ng pagsusuri, ang return code ay magiging katumbas ng 8. Kung ang lisensya ay mag-e-expire sa loob ng isang buwan, ang return code ay magiging katumbas ng 4. Kung ang mga error ay natukoy sa panahon ng pagsusuri, at ang lisensya ay mag-e-expire sa loob ng isang buwan, ang pagbabalik ng code, ang parehong mga halaga ay isusulat: idagdag ang mga numero nang magkasama at kunin ang panghuling return code - 8+4=12. Kaya, sa pamamagitan ng pagsuri sa kaukulang mga piraso, ang impormasyon tungkol sa iba't ibang mga estado ay maaaring makuha sa panahon ng pagsusuri. Ang mga return code ay inilalarawan nang mas detalyado sa "pvs-studio-dotnet (Linux / macOS) Return Codes" na seksyon ng dokumento "Sinusuri ang Visual Studio / MSBuild / .NET Core na mga proyekto mula sa command line gamit ang PVS-Studio".

Sa kasong ito, interesado kami sa lahat ng return code kung saan lumalabas ang 8.

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

Makakatanggap kami ng 1 kapag ang return code ay naglalaman ng kaunting numero na interesado kami, kung hindi, makakatanggap kami ng 0.

Oras na para magdagdag ng pagsusuri sa kahilingan sa pagsasama. Bago natin gawin ito, maghanda tayo ng lugar para sa script. Kailangan namin itong maipatupad kapag may naganap na kahilingan sa pagsasama. Mukhang ganito:

merge:
  script:
  only:
  - merge_requests

Lumipat tayo sa script mismo. Ako ay nahaharap sa katotohanan na ang virtual machine ay walang alam tungkol sa anumang bagay pinanggalingan/panginoon. Kaya't tulungan natin siya ng kaunti:

  - git fetch origin

Ngayon ay nakukuha namin ang pagkakaiba sa pagitan ng mga sanga at i-save ang resulta sa txt file:

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

saan $CI_COMMIT_SHA – hash ng huling commit.

Susunod, sinisimulan naming pag-aralan ang listahan ng mga file gamit ang bandila -f. Inilipat namin ang naunang natanggap na .txt file dito. Well, sa pamamagitan ng pagkakatulad sa buong pagsusuri, tinitingnan namin ang mga return code:

  - 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

Ang kumpletong script para sa pagsuri ng kahilingan sa pagsasama ay magiging ganito:

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

Ang natitira na lang ay magdagdag ng log conversion pagkatapos maproseso ang lahat ng mga script. Ginagamit namin ang label after_script at utility pang-log-converter:

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

Kagamitan pang-log-converter ay isang open source na proyekto na ginagamit upang i-convert ang mga ulat ng error sa parser sa iba't ibang anyo, gaya ng HTML. Ang isang mas detalyadong paglalarawan ng utility ay ibinibigay sa subsection na "Plog Converter Utility" kaugnay na seksyon ng dokumentasyon.

Siyanga pala, kung gusto mong maginhawang magtrabaho sa mga ulat ng .json nang lokal mula sa IDE, iminumungkahi ko ang aming isaksak para sa IDE Rider. Ang paggamit nito ay inilarawan nang mas detalyado sa kaugnay na dokumento.

Para sa kaginhawahan, narito ito .gitlab-ci.yml nang buo:

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

Kapag naidagdag mo na ang lahat sa file, mag-click sa Gumawa ng mga pagbabago. Upang makita kung tama ang lahat, pumunta sa CI / CD -> Pipelines -> Tumatakbo. Magbubukas ang isang window ng virtual machine, sa dulo kung saan dapat mayroong sumusunod:

nakita Nagtagumpay si Job - tagumpay, lahat ay maayos. Ngayon ay maaari mong subukan kung ano ang iyong nagawa.

Mga halimbawa ng trabaho

Para sa isang halimbawa ng trabaho, gumawa tayo ng isang simpleng proyekto (sa panginoon) na maglalaman ng ilang mga file. Pagkatapos nito, sa ibang sangay ay babaguhin lamang namin ang isang file at subukang gumawa ng kahilingan sa pagsasama.

Isaalang-alang natin ang dalawang kaso: kapag ang binagong file ay naglalaman ng isang error at kapag hindi. Una, isang halimbawa na may error.

Sabihin nating mayroong isang file sa master branch Program.cs, na hindi naglalaman ng mga error, ngunit sa ibang sangay nagdagdag ang developer ng maling code at gustong gumawa ng kahilingan sa pagsasama. Anong uri ng pagkakamali ang ginawa niya ay hindi gaanong mahalaga, ang pangunahing bagay ay umiiral ito. Halimbawa, nakalimutan ng operator ihagis (Oo, maling mali):

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

Tingnan natin ang resulta ng pagsusuri ng isang halimbawa na may error. Gayundin upang matiyak na isang file lamang ang na-parse, idinagdag ko ang bandila -r sa linya ng paglulunsad ng pvs-studio-dotnet:

Nakita namin na ang analyzer ay nakakita ng isang error at hindi pinapayagan ang pagsasama ng mga sangay.

Suriin natin ang halimbawa nang walang error. Pagwawasto ng code:

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

Pagsamahin ang mga resulta ng pagsusuri sa kahilingan:

Tulad ng nakikita natin, walang nakitang mga error, at matagumpay ang pagpapatupad ng gawain, na kung ano ang gusto naming suriin.

Konklusyon

Ang pag-alis ng masamang code bago pagsamahin ang mga sanga ay napaka-maginhawa at kaaya-aya. Kaya kung gumagamit ka ng CI/CD, subukang mag-embed ng static analyzer para masuri. Bukod dito, ito ay ginagawa nang simple.

Salamat sa iyo para sa iyong pansin.

Kung nais mong ibahagi ang artikulong ito sa isang madla na nagsasalita ng Ingles, mangyaring gamitin ang link ng pagsasalin: Nikolay Mironov. Pagsusuri ng mga kahilingan sa pagsasama sa GitLab gamit ang PVS-Studio para sa C#.

Pinagmulan: www.habr.com