Анализ на комити и pull request'ове в Travis CI, Buddy и AppVeyor с помощта на PVS-Studio

В анализатора PVS-Studio за езици C и C++ на Linux и macOS, от версия 7.04, се появи тестова възможност да се провери списъкът на указаните файлове. С помощта на новия режим можете да настроите анализатора за проверка на комити и pull request-ове. В тази статия ще бъде описано как да настроите проверка на списъка с променени файлове на проекта в GitHub в популярни CI (Continuous Integration) системи като Travis CI, Buddy и AppVeyor.

Режим за проверка на списъци с файлове

PVS-Studio — това е инструмент за откриване на грешки и потенциални уязвимости в изходния код на програми, написани на езиците C, C++, C# и Java. Работи в 64-битови системи на Windows, Linux и macOS.

В версия PVS-Studio 7.04 за Linux и macOS се появи режим за проверка на списъка с изходни файлове. Това работи за проекти, чиято система за компилация позволява генерирането на файл compile_commands.json. Той е необходим, за да може анализаторът да извлече информация за компилация на указаните файлове. Ако вашата система за компилация не поддържа генерирането на файл compile_commands.json, можете да опитате да генерирате такъв файл с помощта на утилитата Bear.

Също така, режимът на проверка на списъка с файлове може да се използва в комбинация с лог на проследяване strace на стартирания на компилатора (pvs-studio-analyzer trace). За целта първо трябва да направите пълна компилация на проекта и да я проследите, за да може анализаторът да събере пълна информация за параметрите на компилация на всички проверявани файлове.

Обаче, този вариант има съществен недостатък — ще се налага или да извършвате пълна трасировка на компилацията на целия проект при всяко стартиране, което противоречи на идеята за бърза проверка на комит. Или, ако кеширате самия резултат от трасировката, последващите стартирания на анализатора могат да бъдат непълни, ако след трасировката се промени структурата на зависимостите на изходните файлове (например, ако в един от изходните файлове бъде добавен нов #include).

Затова не препоръчваме да използвате режима на проверка на списъка с файлове с лог на трасировка за проверка на комити или pull request-ове. В случай, че можете да правите инкрементална компилация при проверката на комита, обмислете възможността да използвате режима на инкрементален анализ.

Списъкът на изходните файлове за анализ се запазва в текстов файл и се предава на анализатора с помощта на параметъра -S:

pvs-studio-analyzer analyze ... -f build/compile_commands.json -S check-list.txt

В този файл се посочват относителни или абсолютни пътища към файлове, като всеки нов файл трябва да бъде на нов ред. Допустимо е да се посочват не само имена на файлове за анализ, но и различен текст. Анализаторът ще види, че това не е файл и ще игнорира реда. Това може да бъде полезно за коментари, ако файловете бъдат посочени ръчно. Въпреки това, често списъкът с файлове ще бъде генериран по време на анализа в CI, например, това могат да бъдат файлове от комит или pull request.

Сега с помощта на този режим можете бързо да проверите новия код преди да влезе в основната клон на разработка. За да може системата за проверка да реагира на наличието на предупреждения от анализатора, в утилитата plog-converter е добавен флаг —indicate-warnings:

plog-converter ... --indicate-warnings ... -o /path/to/report.tasks ...

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

Забележка. При първото стартиране на анализа списъкът с файлове ще бъде анализиран целия проект, тъй като на анализатора му е необходимо да генерира файл със зависимости на изходните файлове на проекта от заглавните файлове. Това е особеност на анализа на C и C++ файлове. В последствие файлът с зависимости може да бъде кеширан и той ще се обновява автоматично от анализатора. Предимството на проверката на комитите при използване на режима за проверка на списъка с файлове преди използване на режима на инкрементален анализ е, че трябва да кеширате само този файл, а не обектните файлове.

Общи принципи на анализа на pull request

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

Нека разгледаме пример на дърво от комити с две клона:

Нека си представим, че комитът A1 съдържа доста голямо количество код, който вече е проверен. Малко преди това направихме клон от комита A1 и променяхме някакви файлове.

Разбира се, забелязахте, че след A1 се случиха още два комита, но това бяха също така сливане на други клонове, нали не комитим в master. И ето, време е, когато hotfix готово. Затова се появи pull request за сливане B3 и A3.

Разбира се, можеше да се провери целият резултат от тяхното сливане, но това щеше да отнеме твърде много време и да не е оправдано, тъй като са променени само няколко файла. Затова е по-ефективно да анализираме само променените.

За това ще получим разликата между клоновете, като сме в HEAD клона, от който искаме да слеем в master:

git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list

$MERGE_BASE ще разгледаме по-подробно по-късно. Факт е, че не всеки CI сервис предоставя необходимата информация за базата за сливане, затова всеки път трябва да измисляме нови начини за получаване на тези данни. Това ще бъде подробно описано по-долу за всеки от разглежданите уеб-сервизи.

Така, получихме разликата между клоновете, а именно — списък с имената на файловете, които бяха променени. Сега трябва да предадем файла .pvs-pr.list (в който пренасочихме изхода по-горе) на анализатора:

pvs-studio-analyzer analyze -j8 
                            -o PVS-Studio.log 
                            -S .pvs-pr.list

След анализа трябва да конвертираме файлa с логовете (PVS-Studio.log) в удобен за възприемане формат:

plog-converter -t errorfile PVS-Studio.log --cerr -w

Тази команда ще изведе списък с грешки в stderr (стандартния поток за извеждане на съобщения за грешки).

Но ние трябва не само да изведем грешките, но и да уведомим нашия сервис за изграждане и тестване за наличието на проблеми. Затова в конвертора е добавен флаг -W (—indicate-warnings). При наличие дори на едно предупреждение от анализатора, кодът за връщане на утилитата plog-converter ще се промени на 2, което от своя страна ще уведоми CI сервиса за наличието на потенциални грешки в файловете на pull request.

Travis CI

Конфигурацията е извършена под формата на файл .travis.yml. За удобство, препоръчвам всичко да бъде изнесено в отделен bash-скрипт с функции, които ще бъдат извикани от файла .travis.yml (bash име_скрипта.sh име_функция).

Ще добавим необходимия код в скрипта на bash, по този начин ще получим по-голяма функционалност. В секцията install ще напишем следното:

install:
  - bash .travis.sh travis_install

Ако имахте някакви инструкции, можете да ги прехвърлите в скрипта, като премахнете дефисите.

Ще отворим файла .travis.sh и ще добавим инсталирането на анализатора в функцията travis_install():

travis_install() {
  wget -q -O - https://files.viva64.com/etc/pubkey.txt 
    | sudo apt-key add -
  sudo wget -O /etc/apt/sources.list.d/viva64.list 
    https://files.viva64.com/etc/viva64.list
  
  sudo apt-get update -qq
  sudo apt-get install -qq pvs-studio 
}

Сега ще добавим в секцията script стартиране на анализа:

script:
  - bash .travis.sh travis_script

И в bash-скрипта:

travis_script() {
  pvs-studio-analyzer credentials $PVS_USERNAME $PVS_KEY
  
  if [ "$TRAVIS_PULL_REQUEST" != "false" ]; then
    git diff --name-only origin/HEAD > .pvs-pr.list
    pvs-studio-analyzer analyze -j8 
                                -o PVS-Studio.log 
                                -S .pvs-pr.list 
                                --disableLicenseExpirationCheck
  else
    pvs-studio-analyzer analyze -j8 
                                -o PVS-Studio.log 
                                --disableLicenseExpirationCheck
  fi
  
  plog-converter -t errorfile PVS-Studio.log --cerr -w
}

Този код трябва да се изпълни след компилацията на проекта, например, ако имате компилация с CMake:

travis_script() {
  CMAKE_ARGS="-DCMAKE_EXPORT_COMPILE_COMMANDS=On ${CMAKE_ARGS}"
  cmake $CMAKE_ARGS CMakeLists.txt
  make -j8
}

Получавате следното:

travis_script() {
  CMAKE_ARGS="-DCMAKE_EXPORT_COMPILE_COMMANDS=On ${CMAKE_ARGS}"
  cmake $CMAKE_ARGS CMakeLists.txt
  make -j8 
  
  pvs-studio-analyzer credentials $PVS_USERNAME $PVS_KEY
  
  if [ "$TRAVIS_PULL_REQUEST" != "false" ]; then
    git diff --name-only origin/HEAD > .pvs-pr.list
    pvs-studio-analyzer analyze -j8 
                                -o PVS-Studio.log 
                                -S .pvs-pr.list 
                                --disableLicenseExpirationCheck
  else
    pvs-studio-analyzer analyze -j8 
                                -o PVS-Studio.log 
                                --disableLicenseExpirationCheck
  fi
  
  plog-converter -t errorfile PVS-Studio.log --cerr -w
}

Вероятно вече сте забелязали споменатите променливи на средата $TRAVIS_PULL_REQUEST и $TRAVIS_BRANCH. Travis CI ги обявява автоматично:

• $TRAVIS_PULL_REQUEST съдържа номера на pull request-а или false, ако това е обикновена клонка;
• $TRAVIS_REPO_SLUG съдържа името на репозитория на проекта.

Алгоритъмът на работа на тази функция:

Travis CI реагира на кодовете за връщане, така че наличието на предупреждения ще накара услугата да маркира комита като съдържащ грешки.

А сега, нека разгледаме по-подробно тази редица код:

git diff --name-only origin/HEAD > .pvs-pr.list

Факт е, че Travis CI автоматично извършва сливане на клоновете по време на анализа на pull request:

Затова анализираме A4, а не B3->A3. Поради тази особеност трябва да изчислим разликата с A3, който всъщност е връх на клона от origin.

Остана един важен детайл – кеширането на зависимостите на заглавните файлове от компилираните единици на транслация (*.c, *.cc, *.cpp и т.н.). Тези зависимости анализаторът изчислява при първото стартиране в режим на проверка на списъка с файлове и след това ги запазва в директория .PVS-Studio. Travis CI позволява кеширането на папки, така че ще запазим данните на директорията .PVS-Studio/:

cache:
  directories:
    - .PVS-Studio/

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

Buddy

Както и Travis CI, Buddy предлага възможността за автоматизирано изграждане и тестване на проекти, съхранявани в GitHub. За разлика от Travis CI, той се конфигурира през уеб интерфейс (поддържа bash), така че няма нужда да съхранявате файлове с конфигурации в проекта.

Първо, ние трябва да добавим ново действие в конвейера за изграждане:

Ще укажем компилатора, който е бил използван за изграждане на проекта. Обърнете внимание на docker контейнера, който е зададен в това действие. Например, за GCC има специален контейнер:

Сега ще инсталираме PVS-Studio и необходимите утилити:

Добавете следните редове в редактора:

apt-get update && apt-get -y install wget gnupg jq

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

Сега отидете на таба Run (първата икона) и в съответното поле на редактора добавете следния код:

pvs-studio-analyzer credentials $PVS_USERNAME $PVS_KEY

if [ "$BUDDY_EXECUTION_PULL_REQUEST_NO" != '' ]; then
  PULL_REQUEST_ID="pulls/$BUDDY_EXECUTION_PULL_REQUEST_NO"
  MERGE_BASE=`wget -qO - 
    https://api.github.com/repos/${BUDDY_REPO_SLUG}/${PULL_REQUEST_ID} 
    | jq -r ".base.ref"`

  git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck 
                              -S .pvs-pr.list
else
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck
fi

plog-converter -t errorfile PVS-Studio.log --cerr -w

Ако сте чели раздела, посветен на Travs-CI, то този код вече е познат, обаче сега имаме нов етап:

Работата е там, че сега анализираме не резултата от сливането, а HEAD на клона, от който се прави pull request:

Затова сме в условен комит. B3 и трябва да получим разликата с A3:

PULL_REQUEST_ID="pulls/$BUDDY_EXECUTION_PULL_REQUEST_NO"
  MERGE_BASE=`wget -qO - 
    https://api.github.com/repos/${BUDDY_REPO_SLUG}/${PULL_REQUEST_ID} 
    | jq -r ".base.ref"`
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list

За определяне A3 ще използваме GitHub API:

https://api.github.com/repos/${USERNAME}/${REPO}/pulls/${PULL_REQUEST_ID}

Използвахме следните променливи, предоставени от Buddy:

• $BUDDY_EXECUTION_PULL_REQEUST_NO — номер на pull request-а;
• $BUDDY_REPO_SLUG — комбинация от потребителско име и репозитория (например max/test).

Сега ще запазим промените, използвайки бутона долу, и ще активираме анализа на pull request:

В отличие от Travis CI, не е необходимо да посочваме .pvs-studio за кеширане, тъй като Buddy автоматично кешира всички файлове за следващите стартирания. Остава само последното — да запазим потребителското име и паролата за PVS-Studio в Buddy. След запазване на промените, ще се върнем обратно в Pipeline. Трябва да преминем към настройките на променливите и да добавим потребителското име и ключа за PVS-Studio:

След това появата на нов pull request или коммит ще задейства проверката. Ако коммитът съдържа грешки, Buddy ще ги посочи на страницата на pull request.

AppVeyor

Настройката на AppVeyor е подобна на тази на Buddy, тъй като всичко се случва в уеб интерфейса и не е нужно да добавяме файл *.yml в репозитория на проекта.

Ще преминем на таба Settings в прегледа на проекта:

Ще превъртим страницата надолу и ще активираме запазването на кеша за изграждане на pull request:

Сега ще преминем на таба Environment, където ще укажем образа за изграждане и необходимите променливи на средата:

Ако сте прочели предишните раздели, вие вече сте запознати с тези две променливи — PVS_KEY и PVS_USERNAME. Ако не, ще напомня, че те са необходими за проверка на лиценза на анализа на PVS-Studio. В бъдеще ще се срещнем отново с тях в Bash скриптовете.

На същата страница в долната част ще укажем папка за кеширане:

Ако не го направим, ще анализираме вместо няколко файла целия проект, но резултатът ще получим по посочените файлове. Затова е важно да въведем правилното име на директорията.

Сега е време за скрипта за проверка. Отворете таба Tests и изберете Script:

Тази форма трябва да съдържа следния код:

sudo apt-get update && sudo apt-get -y install jq

wget -q -O - https://files.viva64.com/etc/pubkey.txt 
  | sudo apt-key add -
sudo wget -O /etc/apt/sources.list.d/viva64.list 
  https://files.viva64.com/etc/viva64.list

sudo apt-get update && sudo apt-get -y install pvs-studio

pvs-studio-analyzer credentials $PVS_USERNAME $PVS_KEY

PWD=$(pwd -L)
if [ "$APPVEYOR_PULL_REQUEST_NUMBER" != '' ]; then
  PULL_REQUEST_ID="pulls/$APPVEYOR_PULL_REQUEST_NUMBER"
  MERGE_BASE=`wget -qO - 
    https://api.github.com/repos/${APPVEYOR_REPO_NAME}/${PULL_REQUEST_ID} 
    | jq -r ".base.ref"`

  git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck 
                              --dump-files --dump-log pvs-dump.log 
                              -S .pvs-pr.list
else
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck
fi

plog-converter -t errorfile PVS-Studio.log --cerr -w

Нека обърнем внимание на следната част от кода:

PWD=$(pwd -L)
if [ "$APPVEYOR_PULL_REQUEST_NUMBER" != '' ]; then
  PULL_REQUEST_ID="pulls/$APPVEYOR_PULL_REQUEST_NUMBER"
  MERGE_BASE=`wget -qO - 
   https://api.github.com/repos/${APPVEYOR_REPO_NAME}/${PULL_REQUEST_ID} 
   | jq -r ".base.ref"`

  git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck 
                              --dump-files --dump-log pvs-dump.log 
                              -S .pvs-pr.list
else
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck
fi

На пръв поглед, задаването на стойността на командата pwd на променлива, която трябва да съхранява това значение по подразбиране, изглежда странно, но сега ще обясня.

По време на настройването на анализатора в AppVeyor се сблъсках с крайно странно поведение от страна на анализатора. От една страна, всичко работеше правилно, но анализът не стартираше. Прекарах известно време, за да забележа, че сме в директорията /home/appveyor/projects/testcalc/, а анализаторът беше уверен, че сме в /opt/appveyor/build-agent/. Тогава осъзнах, че променливата $PWD малко лъже. Поради тази причина ръчно обнових стойността ѝ преди старта на анализа.

След това всичко продължава както преди:

Сега да разгледаме следния фрагмент:

PULL_REQUEST_ID="pulls/$APPVEYOR_PULL_REQUEST_NUMBER"
MERGE_BASE=`wget -qO - 
  https://api.github.com/repos/${APPVEYOR_REPO_NAME}/${PULL_REQUEST_ID} 
  | jq -r ".base.ref"`

В него получаваме разликата между клоновете, по които е обявен pull request. За целта ни трябват следните променливи на средата:

• $APPVEYOR_PULL_REQUEST_NUMBER — номер на pull request;
• $APPVEYOR_REPO_NAME — име на потребителя и репозитория на проекта.

Заключение

Разбира се, не разгледахме всички възможни услуги за непрекъсната интеграция, но повечето от тях имат много сходна специфика на работа. С изключение на кеширането, всяка услуга изгражда своя "велосипед", така че всичко е различно.

Някъде, като в Travis-CI, няколко реда код и кеширането работи безпроблемно; другаде, като в AppVeyor, просто трябва да посочите папка в настройките; но на места се изисква да създадете уникални ключове и да се опитате да убедите системата да ви позволи да презапишете кеширания фрагмент. Затова, ако искате да настроите анализа на pull request-ите на услуга за непрекъсната интеграция, която не е разгледана по-горе, уверете се първо, че няма да имате проблеми с кеширането.

Благодаря за вниманието. Ако нещо не се получава, пишете ни смело в поддръжка. Ние ще ви помогнем и насочим.

Ако искате да споделите тази статия с англоговоряща аудитория, моля, използвайте линка към превода: Maxim Zvyagintsev. Анализ на комити и pull requests в Travis CI, Buddy и AppVeyor с помощта на PVS-Studio.

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