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

Mahilig sa GitLab ngunit napopoot sa mga error? Gusto mong pagbutihin ang kalidad ng iyong source code? Pagkatapos ay dumating ka sa tamang lugar. Ngayon ay ipapaliwanag namin kung paano i-configure ang PVS-Studio C# analyzer upang suriin ang mga kahilingan sa pagsasama. Magkaroon ng mood na parang unicorn at magsaya.

PVS-Studio — ay isang kagamitan para sa pagtukoy ng mga error at potensyal na kahinaan sa source code ng mga programang nakasulat sa C, C++, C#, at Java. Gumagana ito sa mga 64-bit na sistema. Windows, Linux и macOSKaya nitong suriin ang code na naka-target sa 32-bit, 64-bit, at mga 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 sa ilalim Linux и macOS;
plugin para sa Rider;
bagong file list checking mode.

Mode ng pagsusuri sa listahan ng file

Dati, upang suriin ang mga partikular na file, kailangan mong ipasa sa analyzer ang isang .xml file na naglalaman ng listahan ng file. Gayunpaman, dahil hindi ito masyadong maginhawa, nagdagdag kami ng kakayahang magpasa ng .txt file, na ginagawang mas madali ang mga bagay.

Upang masuri ang mga partikular na file, kailangan mong tumukoy ng flag —sourceFiles (-f) at maglipat ng .txt file 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 i-customize ang pagsusuri ng mga commit o pull request, magagawa mo rin iyon gamit ang mode na ito. Ang pagkakaiba ay nasa listahan ng mga file na susuriin, at ito ay depende sa mga system na iyong ginagamit.

Pagsamahin ang prinsipyo ng pag-verify ng kahilingan

Ang pangunahing punto ng tseke ay upang matiyak na ang mga problema na nakita ng analyzer ay hindi nahuhulog sa pagsasanib panginoon sangay. Hindi rin namin nais na pag-aralan ang buong proyekto sa bawat oras. Lalo na dahil kapag pinagsama 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, ay ililipat sa master branch. Dahil hindi namin gusto ito, nagdaragdag kami ng pagsusuri, at ngayon ang diagram ay ganito ang hitsura:

Sinusuri namin 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 — 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.

NotaAng paraan ng pag-setup ng kapaligiran na inilarawan sa ibaba ay isang posibleng diskarte. Ang layunin ay ipakita ang mga hakbang para sa pag-set up ng kapaligiran na kinakailangan para sa pagsusuri at pagpapatakbo ng analyzer. Marahil, sa iyong kaso, magiging mas pinakamainam na paghiwalayin ang mga hakbang 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 iba pang paraan.

Upang mas maunawaan kung ano ang malapit nang mangyari, iminumungkahi kong tingnan mo ang sumusunod na diagram:

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

Upang mai-install ang PVS-Studio sa pamamagitan ng isang manager ng package, kakailanganin mo ring idagdag ang mga repositoryo ng PVS-Studio. Ang pagdaragdag ng mga repository para sa iba't ibang distribusyon ay inilarawan nang mas detalyado sa ang nauugnay 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.

NotaPakitandaan na ang inilarawang mode (pagsusuri ng mga kahilingan sa pagsasanib) ay nangangailangan ng lisensya ng Enterprise. Samakatuwid, kung gusto mong subukan ang mode na ito, mangyaring tiyaking tukuyin sa field na "Mensahe" na nangangailangan ka 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 kinakailangang format.

Ngayong nasa harap na namin ang gumaganang algorithm, maaari na kaming magpatuloy sa pagsulat ng script. Upang gawin ito, kailangan nating baguhin ang file .gitlab-ci.yml O, kung wala ito, lumikha ng isa. Upang lumikha ng isa, 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_scriptHayaan akong ipaliwanag nang kaunti ang fragment na ito.

Paghahanda para 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 ng PVS-Studio at analyzer:

  - 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.

Pagpapanumbalik 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, ang proyekto ay dapat na matagumpay na bumuo at ang mga dependency nito ay dapat na maibalik (halimbawa, ang mga kinakailangang NuGet packages ay dapat na ma-download).

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

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

Ngayon ay maaari tayong magpatuloy sa pagsusuri. Una, magdagdag tayo ng script para sa buong pagsusuri. Sa bandila -t pumasa tayo sa landas patungo sa solusyon sa watawat -o Ipinasok namin ang landas patungo sa file kung saan isusulat ang mga resulta ng pagsusuri. Interesado din kami sa return code. Sa kasong ito, gusto naming ihinto ang pagsusuri kapag ang return code ay nagsasaad 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

Ang mga return code ay gumagana batay sa prinsipyo ng bitmask. Halimbawa, kung ang pagsusuri ay nagresulta sa mga babala, ang return code ay magiging 8. Kung ang lisensya ay mag-e-expire sa loob ng isang buwan, ang return code ay magiging 4. Kung ang pagsusuri ay nakakita ng mga error at ang lisensya ay mag-e-expire sa loob ng isang buwan, ang return code ay maglalaman ng parehong halaga: pagsamahin ang mga numero upang makuha ang pangwakas na return code—8 + 4 = 12. Kaya, sa pamamagitan ng pagsuri sa mga kaukulang bit, makakakuha ka ng impormasyon tungkol sa iba't ibang estado habang sinusuri. Ang mga return code ay inilalarawan nang mas detalyado sa seksyong "pvs-studio-dotnet Return Codes".Linux / macOS)" dokumento "Sinusuri ang Visual Studio / MSBuild / .NET Core Projects mula sa Command Line gamit ang PVS-Studio".

Sa kasong ito, interesado kami sa lahat ng return code na may kasamang 8.

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

Nakukuha namin ang 1 kapag ang return code ay naglalaman ng kaunting numero na interesado kami, kung hindi, makakakuha kami ng 0.

Oras na para magdagdag ng pagsusuri sa kahilingan sa pagsasama. Bago natin gawin iyon, maghanda tayo ng isang lugar para sa script. Gusto naming tumakbo lang ito kapag may naganap na kahilingan sa pagsasama. Mukhang ganito:

merge:
  script:
  only:
  - merge_requests

Lumipat tayo sa script mismo. Nakatagpo ako ng problema na hindi alam ng virtual machine 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 namin ang pagsusuri ng listahan ng file gamit ang bandila -fIpinapasa namin ang dating nakuhang .txt file dito. At, katulad ng 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 tumakbo ang lahat ng script. Gagamitin natin 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 mga format, tulad ng HTML. Ang isang mas detalyadong paglalarawan ng utility ay ibinigay sa subsection na "Plog Converter Utility". ang nauugnay na seksyon ng dokumentasyon.

Siyanga pala, kung gusto mong maginhawang magtrabaho sa isang .json na ulat 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 pagbabagoUpang matiyak na tama ang lahat, pumunta sa CI / CD -> Pipelines -> TumatakboMagbubukas ang isang window ng virtual machine, sa dulo kung saan dapat mong makita ang sumusunod:

nakita namin Nagtagumpay si Job – Tagumpay, lahat ay mahusay. Ngayon ay maaari naming subukan kung ano ang aming nagawa.

Mga halimbawa ng trabaho

Upang ilarawan ang gawain, gumawa tayo ng isang simpleng proyekto (sa panginoon) na maglalaman ng ilang mga file. Pagkatapos nito, sa kabilang branch, isang file lang ang papalitan namin at susubukan naming gumawa ng kahilingan sa pagsasama.

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

Sabihin nating mayroong isang file sa master branch Program.cs, na walang mga error, at sa isa pang sangay, nagdagdag ang isang developer ng maling code at gustong gumawa ng kahilingan sa pagsasama. Ang eksaktong error ay hindi napakahalaga, ang pangunahing bagay ay na ito ay umiiral. Halimbawa, nakalimutan nila ang isang operator ihagis (Oo, masyado silang mali):

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

Tingnan natin ang resulta ng pagsusuri para sa halimbawang may error. Gayundin, upang matiyak na isang file lamang ang nasuri, nagdagdag ako ng 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 sanga.

Suriin natin ang halimbawa nang walang error. Itama ang code:

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

Mga resulta ng pagsusuri ng kahilingan sa pagsasanib:

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

Konklusyon

Ang pagtanggal ng masamang code bago pagsamahin ang mga sanga ay napaka-kombenyente at kasiya-siya. Kaya, kung gumagamit ka ng CI/CD, subukang magsama ng static analyzer para sa pagsusuri. Lalo na dahil ito ay medyo simple.

Salamat sa iyo para sa iyong pansin.

Kung gusto 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