შერწყმის მოთხოვნების ანალიზი GitLab-ში PVS-Studio-ს გამოყენებით C#-ისთვის

გიყვართ GitLab და გძულთ შეცდომები? გსურთ გააუმჯობესოთ თქვენი წყარო კოდის ხარისხი? მაშინ სწორ ადგილას მოხვედი. დღეს ჩვენ გეტყვით, თუ როგორ უნდა დააკონფიგურიროთ PVS-Studio C# ანალიზატორი შერწყმის მოთხოვნების შესამოწმებლად. გქონდეთ unicorn განწყობა და ბედნიერი კითხვა ყველას.

PVS- სტუდია არის C, C++, C# და Java ენებზე დაწერილი პროგრამების საწყის კოდებში შეცდომებისა და პოტენციური დაუცველობის იდენტიფიცირების ინსტრუმენტი. მუშაობს 64-ბიტიან სისტემებზე Windows-ზე, Linux-ზე და macOS-ზე. შეუძლია გააანალიზოს კოდი, რომელიც შექმნილია 32-ბიტიანი, 64-ბიტიანი და ჩაშენებული ARM პლატფორმებისთვის.

სხვათა შორის, ჩვენ გამოვუშვით PVS-Studio 7.08, რომელშიც ბევრი რამ გავაკეთეთ საინტერესო. მაგალითად:

• C# ანალიზატორი Linux-ისა და macOS-ისთვის;
• მოდული Rider-ისთვის;
• ახალი ფაილების სიის შემოწმების რეჟიმი.

ფაილების სიის შემოწმების რეჟიმი

მანამდე, გარკვეული ფაილების შესამოწმებლად, საჭირო იყო .xml ფაილების სიით ანალიზატორისთვის გადაცემა. მაგრამ რადგან ეს არ არის ძალიან მოსახერხებელი, ჩვენ დავამატეთ .txt გადაცემის შესაძლებლობა, რაც ცხოვრებას ძალიან მარტივს ხდის.

კონკრეტული ფაილების შესამოწმებლად, თქვენ უნდა მიუთითოთ დროშა --sourceFiles (-f) და გადაიტანეთ .txt ფაილების სიით. ეს ასე გამოიყურება:

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

თუ თქვენ გაინტერესებთ ვალდებულების შემოწმების ან მოთხოვნების დაყენება, ასევე შეგიძლიათ ამის გაკეთება ამ რეჟიმის გამოყენებით. განსხვავება იქნება ფაილების სიაში გასაანალიზებლად და დამოკიდებული იქნება იმაზე, თუ რომელ სისტემებს იყენებთ.

შერწყმის მოთხოვნის შემოწმების პრინციპი

შემოწმების მთავარი არსი არის იმის უზრუნველყოფა, რომ ანალიზატორის მიერ შერწყმის დროს აღმოჩენილი პრობლემები არ მოხვდება სამაგისტრო ფილიალი. ჩვენ ასევე არ გვინდა ყოველ ჯერზე გავაანალიზოთ მთელი პროექტი. უფრო მეტიც, ფილიალების გაერთიანებისას, ჩვენ გვაქვს შეცვლილი ფაილების სია. ამიტომ, მე გთავაზობთ გაერთიანების მოთხოვნის შემოწმების დამატებას.

ასე გამოიყურება შერწყმის მოთხოვნა სტატიკური ანალიზატორის განხორციელებამდე:

ანუ ყველა ის შეცდომა, რაც იყო ფილიალში ცვლილებები, გადავა სამაგისტრო ფილიალში. ვინაიდან ეს არ გვინდა, ჩვენ ვამატებთ ანალიზს და ახლა დიაგრამა ასე გამოიყურება:

ჩვენ ვაანალიზებთ ცვლილებები 2 და თუ შეცდომები არ არის, ჩვენ ვიღებთ შერწყმის მოთხოვნას, წინააღმდეგ შემთხვევაში უარვყოფთ მას.

სხვათა შორის, თუ გაინტერესებთ ვალდებულებების ანალიზი და C/C++-ის მოთხოვნები, მაშინ შეგიძლიათ წაიკითხოთ ამის შესახებ აქ.

გიტლაბი

გიტლაბი არის ღია კოდის ვებ-ზე დაფუძნებული DevOps სასიცოცხლო ციკლის ინსტრუმენტი, რომელიც უზრუნველყოფს Git-ისთვის კოდების საცავის მართვის სისტემას საკუთარი ვიკით, საკითხების თვალთვალის სისტემით, CI/CD მილსადენით და სხვა ფუნქციებით.

სანამ შერწყმის მოთხოვნების ანალიზს დაიწყებთ, უნდა დარეგისტრირდეთ და ატვირთოთ თქვენი პროექტი. თუ არ იცით როგორ გააკეთოთ ეს, გირჩევთ მუხლი ჩემი კოლეგა.

შენიშვნა. ქვემოთ აღწერილი გარემოს დაყენების მეთოდი ერთ-ერთია შესაძლო. მიზანია აჩვენოს ნაბიჯები ანალიზისთვის საჭირო გარემოს დასაყენებლად და ანალიზატორის გაშვებისთვის. ალბათ თქვენს შემთხვევაში უფრო ოპტიმალური იქნებოდა გარემოს მომზადების (საცავების დამატება, ანალიზატორის დაყენება) და ანალიზის ეტაპების გამიჯვნა: მაგალითად, დოკერის სურათების მომზადება საჭირო გარემოთი და მათი გამოყენება, ან სხვა მეთოდი.

იმისათვის, რომ უკეთ გავიგოთ რა მოხდება ახლა, მე გთავაზობთ გადახედოთ შემდეგ დიაგრამას:

ანალიზატორს სჭირდება .NET Core SDK 3 მუშაობისთვის, ამიტომ ანალიზატორის დაყენებამდე საჭიროა Microsoft-ის საცავების დამატება, საიდანაც დაინსტალირებული იქნება ანალიზატორისთვის საჭირო დამოკიდებულებები. Microsoft-ის საცავების დამატება Linux-ის სხვადასხვა დისტრიბუციისთვის აღწერილია შესაბამის დოკუმენტში.

PVS-Studio-ს პაკეტის მენეჯერის მეშვეობით დასაყენებლად, ასევე დაგჭირდებათ PVS-Studio-ს საცავების დამატება. სხვადასხვა განაწილებისთვის საცავების დამატება უფრო დეტალურად არის აღწერილი დოკუმენტაციის შესაბამისი ნაწილი.

ანალიზატორის მუშაობისთვის საჭიროა ლიცენზიის გასაღები. შეგიძლიათ მიიღოთ საცდელი ლიცენზია აქ ანალიზატორის ჩამოტვირთვის გვერდი.

შენიშვნა. გთხოვთ, გაითვალისწინოთ, რომ აღწერილი ოპერაციული რეჟიმი (შერწყმის მოთხოვნების ანალიზი) მოითხოვს Enterprise ლიცენზიას. ამიტომ, თუ გსურთ სცადოთ მოქმედების ეს რეჟიმი, არ დაგავიწყდეთ „შეტყობინებების“ ველში მიუთითოთ, რომ გჭირდებათ Enterprise ლიცენზია.

თუ შერწყმის მოთხოვნა მოხდა, მაშინ ჩვენ მხოლოდ უნდა გავაანალიზოთ შეცვლილი ფაილების სია, წინააღმდეგ შემთხვევაში ვაანალიზებთ ყველა ფაილს. ანალიზის შემდეგ, ჩვენ უნდა გადავიყვანოთ ჟურნალები ჩვენთვის საჭირო ფორმატში.

ახლა, მუშაობის ალგორითმი თქვენს თვალწინ, შეგიძლიათ გადახვიდეთ სკრიპტის დაწერაზე. ამისათვის თქვენ უნდა შეცვალოთ ფაილი .gitlab-ci.yml ან, თუ ის არ არსებობს, შექმენით იგი. მის შესაქმნელად, თქვენ უნდა დააჭიროთ თქვენი პროექტის სახელს -> დააყენეთ CI/CD.

ახლა ჩვენ მზად ვართ დავწეროთ სცენარი. ჯერ დავწეროთ კოდი, რომელიც დააინსტალირებს ანალიზატორს და შევიყვანთ ლიცენზიას:

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

ვინაიდან ინსტალაცია და გააქტიურება უნდა მოხდეს ყველა სხვა სკრიპტამდე, ჩვენ ვიყენებთ სპეციალურ ეტიკეტს ადრე_სკრიპტი. ნება მომეცით ცოტა ავხსნა ეს ფრაგმენტი.

ანალიზატორის დაყენების მომზადება:

  - 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 საცავებისა და ანალიზატორის დამატება:

  - 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

$PVS_NAME - მომხმარებლის სახელი.

$PVS_KEY - პროდუქტის გასაღები.

პროექტის დამოკიდებულების აღდგენა სად $CI_PROJECT_DIR - სრული გზა პროექტის დირექტორიაში:

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

სწორი ანალიზისთვის პროექტი წარმატებით უნდა აშენდეს და მისი დამოკიდებულებები უნდა აღდგეს (მაგალითად, უნდა ჩამოიტვირთოს საჭირო NuGet პაკეტები).

თქვენ შეგიძლიათ დააყენოთ გარემოს ცვლადები, რომლებიც შეიცავს ლიცენზიის ინფორმაციას დაწკაპუნებით Setting, და შემდეგ - ჩართვა CI/CD.

ფანჯარაში, რომელიც იხსნება, იპოვეთ ელემენტი ცვლადები, დააჭირეთ ღილაკს მარჯვნივ Expand და დაამატეთ ცვლადები. შედეგი ასე უნდა გამოიყურებოდეს:

ახლა თქვენ შეგიძლიათ გადახვიდეთ ანალიზზე. პირველი, მოდით დავამატოთ სკრიპტი სრული ანალიზისთვის. დროშისკენ -t დროშის გადაწყვეტის გზას გავდივართ -o ჩაწერეთ ფაილის გზა, რომელშიც ჩაიწერება ანალიზის შედეგები. დაბრუნების კოდიც გვაინტერესებს. ამ შემთხვევაში, ჩვენ დაინტერესებული ვართ, რომ ოპერაცია შეჩერდეს, როდესაც დაბრუნების კოდი შეიცავს ინფორმაციას იმის შესახებ, რომ გაფრთხილებები იყო გაცემული ანალიზის დროს. ეს ფრაგმენტი ასე გამოიყურება:

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

დაბრუნების კოდები მუშაობს ბიტი ნიღბის პრინციპით. მაგალითად, თუ ანალიზის შედეგად გაიცა გაფრთხილებები, მაშინ დაბრუნების კოდი იქნება 8-ის ტოლი. თუ ლიცენზიის ვადა ამოიწურება ერთ თვეში, მაშინ დაბრუნების კოდი იქნება 4-ის ტოლი. თუ ანალიზის დროს გამოვლინდა შეცდომები, და ლიცენზია იწურება ერთ თვეში, კოდი დაბრუნდება, დაიწერება ორივე მნიშვნელობა: დაამატეთ რიცხვები და მიიღეთ საბოლოო დაბრუნების კოდი - 8+4=12. ამრიგად, შესაბამისი ბიტების შემოწმებით, ანალიზის დროს შესაძლებელია ინფორმაციის მიღება სხვადასხვა მდგომარეობის შესახებ. დაბრუნების კოდები უფრო დეტალურად არის აღწერილი დოკუმენტის განყოფილებაში "pvs-studio-dotnet (Linux / macOS) დაბრუნების კოდები"Visual Studio / MSBuild / .NET Core პროექტების შემოწმება ბრძანების ხაზიდან PVS-Studio-ს გამოყენებით".

ამ შემთხვევაში, ჩვენ გვაინტერესებს ყველა დაბრუნების კოდი, სადაც 8 ჩანს.

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

ჩვენ მივიღებთ 1-ს, როდესაც დაბრუნების კოდი შეიცავს ჩვენთვის დაინტერესებული ნომრის ბიტს, წინააღმდეგ შემთხვევაში მივიღებთ 0-ს.

დროა დაამატოთ შერწყმის მოთხოვნის ანალიზი. სანამ ამას გავაკეთებთ, მოდით მოვამზადოთ ადგილი სცენარისთვის. ჩვენ გვჭირდება მისი შესრულება მხოლოდ მაშინ, როდესაც მოხდება შერწყმის მოთხოვნა. ეს ასე გამოიყურება:

merge:
  script:
  only:
  - merge_requests

გადავიდეთ თავად სცენარზე. მე დავდექი ფაქტის წინაშე, რომ ვირტუალურმა მანქანამ არაფერი იცის წარმოშობა/ოსტატი. მოდით დავეხმაროთ მას ცოტათი:

  - git fetch origin

ახლა ჩვენ ვიღებთ განსხვავებას ტოტებს შორის და ვინახავთ შედეგს txt ფაილი:

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

Где $CI_COMMIT_SHA – ბოლო დაშვების ჰეში.

შემდეგი, ჩვენ ვიწყებთ ფაილების სიის ანალიზს დროშის გამოყენებით -f. მასში გადავიტანთ ადრე მიღებულ .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

გაერთიანების მოთხოვნის შესამოწმებლად სრული სკრიპტი ასე გამოიყურება:

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

რჩება მხოლოდ ჟურნალის კონვერტაციის დამატება ყველა სკრიპტის დამუშავების შემდეგ. ჩვენ ვიყენებთ ეტიკეტს შემდეგ_სკრიპტი და სასარგებლო ბლოგ-კონვერტორი:

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

კომუნალური ბლოგ-კონვერტორი არის ღია კოდის პროექტი, რომელიც გამოიყენება პარსერის შეცდომის შესახებ ანგარიშების სხვადასხვა ფორმებად გადაქცევისთვის, როგორიცაა HTML. პროგრამის უფრო დეტალური აღწერა მოცემულია ქვეგანყოფილებაში "Plog Converter Utility" დოკუმენტაციის შესაბამისი ნაწილი.

სხვათა შორის, თუ გსურთ მოხერხებულად იმუშაოთ .json ანგარიშებთან ადგილობრივად IDE-დან, მაშინ მე გთავაზობთ ჩვენს დანამატი IDE Rider-ისთვის. მისი გამოყენება უფრო დეტალურად არის აღწერილი შესაბამისი დოკუმენტი.

მოხერხებულობისთვის, აქ არის .gitlab-ci.yml სრულად:

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

მას შემდეგ რაც დაამატებთ ყველაფერს ფაილს, დააწკაპუნეთ შეასრულეთ ცვლილებები. იმისათვის, რომ ნახოთ, რომ ყველაფერი სწორია, გადადით CI / CD -> მილსადენები -> სირბილი. გაიხსნება ვირტუალური მანქანის ფანჯარა, რომლის ბოლოს უნდა იყოს შემდეგი:

დაინახა იობმა წარმატებას მიაღწია - წარმატებები, ყველაფერი კარგადაა. ახლა თქვენ შეგიძლიათ შეამოწმოთ ის, რაც გააკეთეთ.

სამუშაო მაგალითები

სამუშაოს მაგალითისთვის, შევქმნათ მარტივი პროექტი (ში სამაგისტრო) რომელიც შეიცავს რამდენიმე ფაილს. ამის შემდეგ, სხვა ფილიალში ჩვენ შევცვლით მხოლოდ ერთ ფაილს და შევეცდებით შერწყმის მოთხოვნას.

განვიხილოთ ორი შემთხვევა: როდესაც შეცვლილი ფაილი შეიცავს შეცდომას და როდის არა. პირველი, მაგალითი შეცდომით.

ვთქვათ, არის ფაილი სამაგისტრო ფილიალში პროგრამა.cs, რომელიც არ შეიცავს შეცდომებს, მაგრამ სხვა ფილიალში დეველოპერმა დაამატა მცდარი კოდი და სურს შერწყმის მოთხოვნა. როგორი შეცდომა დაუშვა, არც ისე მნიშვნელოვანია, მთავარია ის არსებობს. მაგალითად, ოპერატორს დაავიწყდა გადაყარეთ (დიახ, ასე არასწორი):

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

მოდით შევხედოთ შეცდომით მაგალითის ანალიზის შედეგს. ასევე იმისთვის, რომ დავრწმუნდე, რომ მხოლოდ ერთი ფაილი იყო გაანალიზებული, მე დავამატე დროშა -r pvs-studio-dotnet გაშვების ხაზზე:

ჩვენ ვხედავთ, რომ ანალიზატორმა აღმოაჩინა შეცდომა და არ დაუშვა ტოტების შერწყმა.

მოდით შევამოწმოთ მაგალითი შეცდომის გარეშე. კოდის გასწორება:

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

გაერთიანების მოთხოვნის ანალიზის შედეგები:

როგორც ვხედავთ, შეცდომები არ იქნა ნაპოვნი და დავალების შესრულება წარმატებით დასრულდა, რისი შემოწმებაც გვინდოდა.

დასკვნა

ცუდი კოდის ამოღება ტოტების შერწყმამდე ძალიან მოსახერხებელი და სასიამოვნოა. ასე რომ, თუ იყენებთ CI/CD-ს, სცადეთ სტატიკური ანალიზატორის ჩასმა შესამოწმებლად. უფრო მეტიც, ეს კეთდება საკმაოდ მარტივად.

დიდი მადლობა ყურადღებისთვის.

თუ გსურთ გაუზიაროთ ეს სტატია ინგლისურენოვან აუდიტორიას, გთხოვთ, გამოიყენოთ თარგმანის ბმული: ნიკოლაი მირონოვი. შერწყმის მოთხოვნების ანალიზი GitLab-ში PVS-Studio-ს გამოყენებით C#-ისთვის.

წყარო: www.habr.com