Анализ на ангажименти и заявки за изтегляне в Travis CI, Buddy и AppVeyor с помощта на PVS-Studio

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Общи принципи на анализа на заявка за изтегляне

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

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

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

Вие, разбира се, забелязахте това след това A1 възникнаха още два ангажимента, но това също бяха сливания на други клонове, защото ние не се ангажираме с майстор. И сега дойде времето, когато корекция готов. Затова се появи пул заявка за сливането 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-конвертор ще се промени на 2, което от своя страна ще информира CI услугата за наличието на потенциални грешки във файловете за заявка за изтегляне.

Травис CI

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

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

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

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

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

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

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

Факт е, че Travis CI автоматично обединява клонове, докато анализира заявка за изтегляне:

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

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

cache:
  directories:
    - .PVS-Studio/

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

Приятелю

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

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

Нека посочим компилатора, който е използван за изграждане на проекта. Обърнете внимание на докер контейнера, който е инсталиран в това действие. Например, има специален контейнер за 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 на клона, от който е направена заявката за изтегляне:

Така че ние сме в условен ангажимент 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 — номер на заявка за изтегляне;
• $BUDDY_REPO_SLUG — комбинация от потребителско име и хранилище (например max/test).

Сега нека запазим промените, като използваме бутона по-долу и активираме анализа на заявката за изтегляне:

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

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

AppVeyor

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

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

Нека превъртим надолу тази страница и активираме запазването на кеша за събиране на заявки за изтегляне:

Сега нека отидем в раздела Околна среда, където посочваме изображението за сглобяване и необходимите променливи на средата:

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

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

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

Сега е време за тестване на скрипта. Отворете раздела Тестове и изберете Скрипт:

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

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"`

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

• $APPVEYOR_PULL_REQUEST_NUMBER — номер на заявка за изтегляне;
• $APPVEYOR_REPO_NAME - потребителско име и хранилище на проекта.

Заключение

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

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

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

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

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