Анализ на комитите и 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

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

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

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

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

Travis CI

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

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

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:
  - 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-а или неверно, ако е обикновен клон;
• $TRAVIS_REPO_SLUG съхранява името на репозитория на проекта.

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

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

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

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

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

Затова анализираме A4, а не B3->A3. Поради тази особеност трябва да изчисляваме разликата с А3, което всъщност е върхът на клона от 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

Ако сте прочели раздела, посветен на Travis-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 ще използваме API на GitHub:

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

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

• $BUDDY_EXECUTION_PULL_REQUEST_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