Анализ на merge request'ове в GitLab с PVS-Studio за C#

Обичате GitLab и не обичате грешки? Искате да повишите качеството на изходния код? Тогава сте на правилното място. Днес ще разкажем как да настроите C# анализатора PVS-Studio за проверка на merge request'ове. На всички желая добро настроение и приятно четене.

PVS-Studio е инструмент за откриване на грешки и потенциални уязвимости в изходния код на програми, написани на 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

Ако ви интересува да настроите проверка на комити или pull requests, можете да направите това, използвайки този режим. Разликата ще бъде в получаването на списък с файлове за анализ и зависи от системите, които използвате.

Принцип на проверка на merge request

Основната цел на проверката е проблемите, открити от анализатора, да не попаднат в master клон. Също така не искаме всеки път да анализираме проекта изцяло. Тем повече, че при сливане на клоновете имаме списък с променени файлове. Затова предлагам да добавим проверка на merge request.

Така изглежда merge request преди внедряване на статичния анализатор:

Тоест всички грешки, които били в клона changes, ще преминат в главния клон. Понеже не желаем това, добавяме анализ, и сега схемата изглежда по следния начин:

Анализиране на changes2 и, ако няма грешки, приемаме merge request, а в противен случай го отхвърляме.

Между другото, ако ви интересува анализ на комити и pull request'ове за C/C++, можете да прочетете за него тук..

GitLab

GitLab — инструмент за управление жизнения на DevOps с отворен код, представляващ система за управление на кодови хранилища за Git с вградена уики, система за проследяване на грешки, CI/CD пайплайн и други функции.

Преди да започнете с анализа на merge request-ите, е необходимо да се регистрирате и да качите проекта си. Ако не знаете как да го направите, предлагам статия колегата ми.

Забележка. Представеният по-долу начин за настройка на среда е един от възможните. Целта е да се покажат стъпките за настройка на необходимата среда за анализ и стартиране на анализатора. Възможно е в случая ви по-оптимално да бъде разделянето на етапите на подготовка на средата (добавяне на репозитории, инсталиране на анализатора) и анализ: например, подготовка на Docker образи с необходимата среда и тяхното използване или някакъв друг метод.

За по-ясно разбиране какво ще се случва сега, предлагам да погледнете следната схема:

Анализаторът изисква .NET Core SDK 3, затова преди инсталацията на анализатора е необходимо да добавите репозиториите на Microsoft, от които ще бъдат инсталирани необходимите зависимости за анализатора. Добавянето на репозитории на Microsoft за различни дистрибуции на Linux е описано в съответния документ.

За инсталиране на PVS-Studio чрез пакетен мениджър също ще бъде необходимо да добавите репозиториите на PVS-Studio. Добавянето на репозитории за различни дистрибуции е по-подробно описано в съответния раздел на документацията.

За работа на анализатора е необходим лицензен ключ. Можете да получите пробен лиценз на страницата за изтегляне на анализатора.

Забележка. Обърнете внимание, че за описания режим на работа (анализ на merge requests) е нужна Enterprise лицензия. Затова, ако желаете да пробвате този режим на работа, в полето "Съобщение" не забравяйте да посочите, че ви е нужна именно Enterprise лицензия.

Ако се случи merge request, ще ни е необходим анализ само на списъка с променените файлове, а в противен случай анализираме всички файлове. След анализа е необходимо да конвертираме логовете в необходимия формат.

Сега, имайки алгоритъма на работа пред очите си, можем да пристъпим към написването на скрипта. За да го направим, е необходимо да променим файла .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

Тъй като инсталирането и активирането трябва да се извършат преди всички останали скриптове, използваме специален етикет before_script. Нека обясня този фрагмент.

Подготовка за инсталирането на анализатора:

  - 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 передаваме пътя до solution, в параметъра -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 request. Преди да направим това, да подготвим място за скрипта. Необходимо е да се изпълнява само когато настъпи merge request. Изглежда така:

merge:
  script:
  only:
  - merge_requests

Да преминем към самия скрипт. Справих се с това, че виртуалната машина не знае нищо за origin/master. Затова й помагаме малко:

  - 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 request ще изглежда така:

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:

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

Утилита plog-converter — това е проект с отворен код, който се използва за преобразуване на отчети за грешки от анализатора в различни формати, например HTML. По-подробно описание на утилитата е представено в подглавата "Утилита Plog Converter" съответния раздел на документацията.

Между другото, ако искате да работите удобно с .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

След като добавите всичко в файла, натиснете на Commit changes. За да видите, че всичко е наред, влезте в CI/CD -> Pipelines -> В процес на изпълнение. Ще се отвори прозорец на виртуална машина, в края на който трябва да има следното:

Видяхте Job succeeded – успех, всичко е добре. Сега можете да тествате направеното.

Примери за работа

За пример ще създадем прост проект (в master) който ще има няколко файла. След това в друга клон ще променим само един файл и ще се опитаме да направим merge request.

Ще разгледаме два случая: когато промененият файл съдържа грешка и когато не. Първо, пример с грешка.

Да предположим, че в master клона има файл Program.cs, който не съдържа грешки, а в друг клон разработчикът е добавил грешен код и иска да направи merge request. Каква точно грешка е допуснал – не е толкова важно, важно е, че такава съществува. Например, забравил е оператора throw (да, така грешат):

void MyAwesomeMethod(String name)
{
  if (name == null)
    new ArgumentNullException(....);
  // направи нещо
  ....
}

Нека разгледаме резултата от анализа на примера с грешка. Също така, за да се уверим, че само един файл е бил анализиран, добавих флага -r в командния ред на pvs-studio-dotnet:

Виждаме, че анализаторът е открил грешка и не е позволил сливането на клоновете.

Проверяваме примера без грешка. Поправяме кода:

void MyAwesomeMethod(String name)
{
  if (name == null)
    throw new ArgumentNullException(....);
  // направи нещо
  ....
}

Резултатите от анализа на merge request:

Както виждаме, грешки не са намерени и изпълнението на задачата е преминало успешно, което искахме да проверим.

Заключение

Отстраняването на лош код преди сливането на клоновете е много удобно и приятно. Затова, ако използвате CI/CD, опитайте да вградите статичен анализатор за проверка. Особено, тъй като това се прави доста лесно.

Благодаря за вниманието.

Ако искате да споделите тази статия с англоговоряща аудитория, моля, използвайте линка към превода: Nikolay Mironov. Анализ на merge requests в GitLab с PVS-Studio за C#.

Източник: habr.com