🥇تجزیه و تحلیل درخواست های ادغام در GitLab با استفاده از PVS-Studio برای C#

عاشق GitLab هستید و از اشکالات متنفر هستید؟ آیا می خواهید کیفیت کد منبع خود را بهبود بخشید؟ سپس شما به جای مناسب آمده اید. امروز به شما خواهیم گفت که چگونه تحلیلگر PVS-Studio C# را برای بررسی درخواست های ادغام پیکربندی کنید. حال و هوای تک شاخ داشته باشید و برای همه مطالعه شاد داشته باشید.

PVS Studio ابزاری برای شناسایی خطاها و آسیب پذیری های احتمالی در کد منبع برنامه های نوشته شده به زبان های C، C++، C# و جاوا است. روی سیستم های 64 بیتی در ویندوز، لینوکس و macOS کار می کند. می تواند کدهای طراحی شده برای پلتفرم های 32 بیتی، 64 بیتی و تعبیه شده ARM را تجزیه و تحلیل کند.

به هر حال، ما PVS-Studio 7.08 را منتشر کردیم که در آن کارهای زیادی انجام دادیم جالب هست. به عنوان مثال:

تحلیلگر سی شارپ برای لینوکس و macOS؛
پلاگین برای رایدر.
حالت بررسی لیست فایل جدید

حالت بررسی لیست فایل

قبلاً برای بررسی برخی فایل‌ها، لازم بود یک xml. با لیستی از فایل‌ها به آنالایزر ارسال شود. اما از آنجایی که این کار خیلی راحت نیست، ما قابلیت انتقال .txt را اضافه کرده ایم که زندگی را بسیار ساده می کند.

برای بررسی فایل های خاص، باید پرچم را مشخص کنید --فایل های منبع (-f) و txt را با لیستی از فایل ها انتقال دهید. به نظر می رسد این است:

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

اگر علاقه مند به تنظیم commit check یا pull requests هستید، می توانید با استفاده از این حالت نیز این کار را انجام دهید. تفاوت در دریافت لیستی از فایل ها برای تجزیه و تحلیل خواهد بود و به سیستم هایی که استفاده می کنید بستگی دارد.

اصل بررسی درخواست ادغام

ماهیت اصلی بررسی این است که اطمینان حاصل شود که مشکلات شناسایی شده توسط تحلیلگر در طول ادغام در داخل استاد شاخه. ما همچنین نمی خواهیم هر بار کل پروژه را تجزیه و تحلیل کنیم. علاوه بر این، هنگام ادغام شاخه ها، لیستی از فایل های تغییر یافته داریم. بنابراین، پیشنهاد می کنم یک بررسی درخواست ادغام اضافه کنید.

این چیزی است که یک درخواست ادغام قبل از اجرای یک تحلیلگر استاتیک به نظر می رسد:

یعنی تمام خطاهایی که در شعبه بود تغییرات، به شعبه اصلی منتقل می شود. از آنجایی که ما این را نمی‌خواهیم، تجزیه و تحلیل را اضافه می‌کنیم و اکنون نمودار به شکل زیر است:

تحلیل می کنیم تغییرات 2 و اگر خطایی وجود نداشته باشد، درخواست ادغام را می پذیریم، در غیر این صورت آن را رد می کنیم.

به هر حال، اگر شما علاقه مند به تجزیه و تحلیل commit و کشش درخواست ها برای C/C++ هستید، می توانید در مورد آن مطالعه کنید. اینجا.

گیتلب

گیتلب یک ابزار چرخه حیات DevOps مبتنی بر وب منبع باز است که یک سیستم مدیریت مخزن کد برای Git با ویکی خود، سیستم ردیابی مشکل، خط لوله CI/CD و سایر ویژگی‌ها ارائه می‌کند.

قبل از شروع تجزیه و تحلیل درخواست های ادغام، باید پروژه خود را ثبت و آپلود کنید. اگر نمی دانید چگونه این کار را انجام دهید، پس پیشنهاد می کنم یک مقاله همکار من.

یادداشت. روش تنظیم محیطی که در زیر توضیح داده شده است یکی از موارد ممکن است. هدف نشان دادن مراحل تنظیم محیط لازم برای تجزیه و تحلیل و راه اندازی تحلیلگر است. شاید در مورد شما بهینه تر باشد که مراحل آماده سازی محیط (افزودن مخازن، نصب آنالایزر) و تجزیه و تحلیل را از هم جدا کنید: مثلاً تهیه تصاویر داکر با محیط لازم و استفاده از آنها یا روش دیگری.

برای درک بهتر آنچه اکنون اتفاق خواهد افتاد، پیشنهاد می کنم به نمودار زیر نگاه کنید:

آنالایزر برای کار کردن به .NET Core SDK 3 نیاز دارد، بنابراین قبل از نصب آنالایزر باید مخازن مایکروسافت را اضافه کنید که وابستگی های مورد نیاز برای آنالایزر از آنجا نصب می شوند. افزودن مخازن مایکروسافت برای توزیع های مختلف لینوکس در سند مربوطه شرح داده شده است.

برای نصب 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 لازم باید دانلود شوند).

می توانید با کلیک کردن، متغیرهای محیطی حاوی اطلاعات مجوز را تنظیم کنید محیط، و بعد از آن CI/CD.

در پنجره ای که باز می شود، مورد را پیدا کنید متغیر، روی دکمه سمت راست کلیک کنید گسترش و متغیرها را اضافه کنید. نتیجه باید به این صورت باشد:

حالا می توانید به تحلیل بروید. ابتدا یک اسکریپت برای تجزیه و تحلیل کامل اضافه می کنیم. به پرچم -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

اکنون تفاوت بین شاخه ها را می گیریم و نتیجه را در آن ذخیره می کنیم کلیپ برد چند منظوره فایل:

  - 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

تنها چیزی که باقی می ماند این است که پس از پردازش همه اسکریپت ها، تبدیل ورود به سیستم را اضافه کنید. ما از برچسب استفاده می کنیم پس از_اسکریپت و سودمندی Plog-Converter:

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

سودمندی Plog-Converter یک پروژه متن باز است که برای تبدیل گزارش های خطای تجزیه کننده به اشکال مختلف مانند HTML استفاده می شود. توضیح دقیق تر این ابزار در بخش فرعی "ابزار تبدیل Plog" ارائه شده است. بخش مربوطه از اسناد.

به هر حال، اگر می خواهید به راحتی با گزارش های 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 -> خطوط لوله -> محل دویدن و پیاده روی . یک پنجره ماشین مجازی باز می شود که در انتهای آن باید موارد زیر وجود داشته باشد:

اره ایوب موفق شد - موفقیت، همه چیز خوب است. اکنون می توانید آنچه را که انجام داده اید آزمایش کنید.

نمونه های کار

برای مثالی از کار، اجازه دهید یک پروژه ساده ایجاد کنیم (در استاد) که حاوی چندین فایل خواهد بود. پس از آن، در یک شعبه دیگر فقط یک فایل را تغییر می دهیم و سعی می کنیم درخواست ادغام کنیم.

بیایید دو مورد را در نظر بگیریم: زمانی که فایل اصلاح شده حاوی خطا است و زمانی که حاوی خطا نیست. ابتدا یک مثال با خطا.

فرض کنید یک فایل در شاخه اصلی وجود دارد Program.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

تجزیه و تحلیل درخواست های ادغام در GitLab با استفاده از PVS-Studio برای C#

حالت بررسی لیست فایل

اصل بررسی درخواست ادغام

گیتلب

نمونه های کار

نتیجه

اضافه کردن نظر انصراف از پاسخ