🥇Pagsusuri ng mga commit at pull request sa Travis CI, Buddy at AppVeyor gamit ang PVS-Studio

Sa PVS-Studio analyzer para sa mga wikang C at C++ sa Linux at macOS, simula sa bersyon 7.04, lumitaw ang isang pagpipilian sa pagsubok upang suriin ang listahan ng mga tinukoy na file. Gamit ang bagong mode, maaari mong i-configure ang analyzer para suriin ang mga commit at pull request. Sasabihin sa iyo ng artikulong ito kung paano i-set up ang pagsuri sa listahan ng mga binagong file ng isang proyekto sa GitHub sa mga sikat na CI (Continuous Integration) system gaya ng Travis CI, Buddy at AppVeyor.

Mode ng pagsusuri sa listahan ng file

PVS-Studio ay isang tool para sa pagtukoy ng mga error at potensyal na kahinaan sa source code ng mga program na nakasulat sa C, C++, C# at Java. Gumagana sa 64-bit system sa Windows, Linux at macOS.

Sa bersyon ng PVS-Studio 7.04 para sa Linux at macOS, lumitaw ang isang mode para sa pagsuri sa listahan ng mga source file. Gumagana ito para sa mga proyekto na nagbibigay-daan sa iyo ang build system na bumuo ng isang file compile_commands.json. Ito ay kinakailangan para sa analyzer upang kunin ang impormasyon tungkol sa compilation ng tinukoy na mga file. Kung hindi sinusuportahan ng iyong build system ang pagbuo ng compile_commands.json file, maaari mong subukang bumuo ng ganoong file gamit ang utility Tumungo.

Gayundin, ang file list checking mode ay maaaring gamitin kasama ng strace trace log ng mga paglulunsad ng compiler (pvs-studio-analyzer trace). Upang gawin ito, kakailanganin mo munang magsagawa ng isang buong build ng proyekto at subaybayan ito upang ang analyzer ay mangolekta ng kumpletong impormasyon tungkol sa mga parameter ng compilation ng lahat ng mga file na sinusuri.

Gayunpaman, ang pagpipiliang ito ay may isang makabuluhang disbentaha - kakailanganin mong magsagawa ng isang buong build na bakas ng buong proyekto sa bawat oras na patakbuhin mo ito, na sa kanyang sarili ay sumasalungat sa ideya ng mabilis na pagsuri ng isang commit. O, kung ini-cache mo mismo ang resulta ng trace, maaaring hindi kumpleto ang mga kasunod na pagpapatakbo ng analyzer kung magbabago ang dependency structure ng source file pagkatapos ng trace (halimbawa, isang bagong #include ang idaragdag sa isa sa mga source file).

Samakatuwid, hindi namin inirerekomenda ang paggamit ng file list check mode na may trace log upang suriin ang mga commit o pull request. Kung sakaling makakagawa ka ng incremental build kapag sinusuri ang isang commit, isaalang-alang ang paggamit ng mode incremental analysis.

Ang listahan ng mga source file para sa pagsusuri ay naka-save sa isang text file at ipinasa sa analyzer gamit ang parameter -S:

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

Ang file na ito ay tumutukoy sa mga kamag-anak o ganap na landas sa mga file, at ang bawat bagong file ay dapat na nasa isang bagong linya. Katanggap-tanggap na tukuyin hindi lamang ang mga pangalan ng file para sa pagsusuri, kundi pati na rin ang iba't ibang teksto. Makikita ng analyzer na hindi ito file at babalewalain ang linya. Maaari itong maging kapaki-pakinabang para sa pagkomento kung manu-manong tinukoy ang mga file. Gayunpaman, madalas na isang listahan ng mga file ang bubuo sa panahon ng pagsusuri sa CI, halimbawa, ang mga ito ay maaaring mga file mula sa isang commit o pull request.

Ngayon, gamit ang mode na ito, maaari mong mabilis na suriin ang bagong code bago ito makapasok sa pangunahing sangay ng pag-unlad. Upang matiyak na ang sistema ng pag-scan ay tumutugon sa mga babala ng analyzer, ang utility pang-log-converter idinagdag ang bandila --indicate-babala:

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

Gamit ang flag na ito, magbabalik ang converter ng hindi zero na code kung may mga babala sa ulat ng analyzer. Gamit ang return code, maaari mong i-block ang isang precommit hook, commit, o pull request, at ang nabuong ulat ng analyzer ay maaaring ipakita, ibahagi, o ipadala sa pamamagitan ng email.

Tandaan. Kapag una mong sinimulan ang pagsusuri ng isang listahan ng mga file, ang buong proyekto ay susuriin, dahil ang analyzer ay kailangang bumuo ng isang file ng mga dependencies ng project source file sa header file. Ito ay isang tampok ng pagsusuri ng mga C at C++ na file. Sa hinaharap, maaaring i-cache ang dependency file at awtomatiko itong ia-update ng analyzer. Ang bentahe ng checking commits kapag gumagamit ng file list checking mode sa paggamit ng incremental analysis mode ay kailangan mo lang i-cache ang file na iyon at hindi ang object file.

Pangkalahatang mga prinsipyo ng pagsusuri ng kahilingan sa paghila

Ang pagsusuri sa buong proyekto ay tumatagal ng maraming oras, kaya makatuwiran na suriin lamang ang isang partikular na bahagi nito. Ang problema ay kailangan mong paghiwalayin ang mga bagong file mula sa iba pang mga file ng proyekto.

Tingnan natin ang isang halimbawa ng commit tree na may dalawang sanga:

Isipin natin ang commit na iyon A1 naglalaman ng medyo malaking halaga ng code na nasubok na. Medyo kanina gumawa kami ng branch from the commit A1 at binago ang ilang mga file.

Siyempre, napansin mo iyon pagkatapos A1 dalawa pang commit ang naganap, ngunit ito ay mga pagsasanib din ng ibang mga branch, dahil hindi kami nangangako na panginoon. At ngayon ay dumating ang oras kung kailan hotfix handa na. Kaya naman may lumabas na pull request para sa merger B3 и A3.

Siyempre, posibleng suriin ang buong resulta ng kanilang pagsasanib, ngunit ito ay masyadong matagal at hindi makatwiran, dahil kaunti lang ang mga file na binago. Samakatuwid, mas mahusay na pag-aralan lamang ang mga nabago.

Upang gawin ito, makuha namin ang pagkakaiba sa pagitan ng mga sangay, na nasa HEAD ng sangay kung saan nais naming pagsamahin sa master:

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

$MERGE_BASE titingnan natin ito nang detalyado mamaya. Ang katotohanan ay hindi lahat ng serbisyo ng CI ay nagbibigay ng kinakailangang impormasyon tungkol sa database para sa pagsasama, kaya sa bawat oras na kailangan mong makabuo ng mga bagong paraan upang makuha ang data na ito. Ito ay ilalarawan nang detalyado sa ibaba sa bawat isa sa mga inilarawang serbisyo sa web.

Kaya, nakuha namin ang pagkakaiba sa pagitan ng mga sangay, o mas tiyak, isang listahan ng mga pangalan ng file na binago. Ngayon kailangan nating ibigay ang file .pvs-pr.list (na-redirect namin ang output sa itaas dito) sa analyzer:

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

Pagkatapos ng pagsusuri, kailangan naming i-convert ang log file (PVS-Studio.log) sa isang madaling basahin na format:

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

Ililista ng command na ito ang mga error sa stderr (karaniwang output ng mensahe ng error).

Ngayon lamang kailangan naming hindi lamang magpakita ng mga error, ngunit ipaalam din sa aming serbisyo para sa pagpupulong at pagsubok tungkol sa pagkakaroon ng mga problema. Para sa layuning ito, isang bandila ang idinagdag sa converter -W (--indicate-babala). Kung mayroong hindi bababa sa isang babala ng analyzer, ang utility return code pang-log-converter ay magbabago sa 2, na, sa turn, ay ipaalam sa serbisyo ng CI tungkol sa pagkakaroon ng mga potensyal na error sa mga pull request file.

Travis CI

Ang pagsasaayos ay ginawa bilang isang file .travis.yml. Para sa kaginhawahan, ipinapayo ko sa iyo na ilagay ang lahat sa isang hiwalay na script ng bash na may mga function na tatawagin mula sa file .travis.yml (bash script_name.sh function_name).

Idaragdag namin ang kinakailangang code sa script sa malakas na palo, sa paraang ito makakakuha tayo ng higit pang functionality. Sa seksyon install isulat natin ang sumusunod:

install:
  - bash .travis.sh travis_install

Kung mayroon kang anumang mga tagubilin, maaari mong ilipat ang mga ito sa script, alisin ang mga gitling.

Buksan natin ang file .travis.sh at idagdag ang setting ng analyzer sa function 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 
}

Ngayon idagdag natin sa seksyon script patakbuhin ang pagsusuri:

script:
  - bash .travis.sh travis_script

At sa script ng 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
}

Ang code na ito ay kailangang patakbuhin pagkatapos buuin ang proyekto, halimbawa, kung mayroon kang build sa CMake:

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

Ito ay magiging ganito:

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
}

Marahil ay napansin mo na ang mga variable ng kapaligiran na ito $TRAVIS_PULL_REQUEST и $TRAVIS_BRANCH. Idineklara sila ng Travis CI nang nakapag-iisa:

$TRAVIS_PULL_REQUEST iniimbak ang numero ng kahilingan sa paghila o hindi totoo, kung ito ay isang regular na sangay;
$TRAVIS_REPO_SLUG nag-iimbak ng pangalan ng repositoryo ng proyekto.

Ang algorithm para sa function na ito:

Tumutugon ang Travis CI sa mga return code, kaya ang pagkakaroon ng mga babala ay magsasabi sa serbisyo na markahan ang commit bilang naglalaman ng mga error.

Ngayon tingnan natin ang linyang ito ng code:

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

Ang katotohanan ay awtomatikong pinagsasama ng Travis CI ang mga sangay habang sinusuri ang isang kahilingan sa paghila:

Kaya pinag-aaralan namin A4At hindi B3->A3. Dahil sa tampok na ito, kailangan nating kalkulahin ang pagkakaiba sa A3, na eksaktong tuktok ng sangay mula sa pinagmulan.

May natitira pang mahalagang detalye - pag-cache ng mga dependency ng mga file ng header sa mga pinagsama-samang unit ng pagsasalin (*.c, *.cc, *.cpp, atbp.). Kinakalkula ng analyzer ang mga dependency na ito noong una itong inilunsad sa mode ng pagsuri sa isang listahan ng mga file at pagkatapos ay i-save ang mga ito sa direktoryo ng .PVS-Studio. Pinapayagan ka ng Travis CI na mag-cache ng mga folder, kaya ise-save namin ang data ng direktoryo .PVS-Studio/:

cache:
  directories:
    - .PVS-Studio/

Ang code na ito ay kailangang idagdag sa file .travis.yml. Ang direktoryo na ito ay nag-iimbak ng iba't ibang data na nakolekta pagkatapos ng pagsusuri, na makabuluhang magpapabilis sa mga kasunod na pagpapatakbo ng pagsusuri sa listahan ng file o incremental na pagsusuri. Kung hindi ito nagawa, susuriin ng analyzer ang lahat ng mga file sa bawat oras.

Pare

Tulad ni Travis CI, Pare nagbibigay ng kakayahang awtomatikong bumuo at sumubok ng mga proyektong nakaimbak sa GitHub. Hindi tulad ng Travis CI, naka-configure ito sa web interface (magagamit ang suporta sa bash), kaya hindi na kailangang mag-imbak ng mga configuration file sa proyekto.

Una sa lahat, kailangan nating magdagdag ng bagong aksyon sa linya ng pagpupulong:

Ipahiwatig natin ang compiler na ginamit sa pagbuo ng proyekto. Pansinin ang docker container na naka-install sa pagkilos na ito. Halimbawa, mayroong isang espesyal na lalagyan para sa GCC:

Ngayon ay i-install natin ang PVS-Studio at ang mga kinakailangang kagamitan:

Idagdag natin ang mga sumusunod na linya sa editor:

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

Ngayon, pumunta tayo sa tab na Run (unang icon) at idagdag ang sumusunod na code sa kaukulang field ng editor:

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

Kung nabasa mo ang seksyon sa Travs-CI, kung gayon ang code na ito ay pamilyar na sa iyo, gayunpaman, ngayon ay may isang bagong yugto:

Ang katotohanan ay ngayon hindi namin sinusuri ang resulta ng pagsasama, ngunit ang HEAD ng sangay kung saan ginawa ang kahilingan sa paghila:

Kaya nasa conditional commit tayo B3 at kailangan nating makuha ang pagkakaiba mula sa 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

Upang matukoy A3 Gamitin natin ang GitHub API:

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

Ginamit namin ang mga sumusunod na variable na ibinibigay ni Buddy:

$BUDDY_EXECUTION_PULL_REQEUST_NO — pull request number;
$BUDDY_REPO_SLUG — isang kumbinasyon ng username at repository (halimbawa max/test).

Ngayon, i-save natin ang mga pagbabago gamit ang button sa ibaba at paganahin ang pagsusuri ng pull request:

Hindi tulad ng Travis CI, hindi namin kailangang tukuyin .pvs-studio para sa pag-cache, dahil awtomatikong ini-cache ni Buddy ang lahat ng mga file para sa mga susunod na paglulunsad. Samakatuwid, ang huling bagay na natitira ay i-save ang login at password para sa PVS-Studio sa Buddy. Pagkatapos i-save ang mga pagbabago, ibabalik tayo sa Pipeline. Kailangan nating magpatuloy sa pag-set up ng mga variable at pagdaragdag ng login at key para sa PVS-Studio:

Pagkatapos nito, ang paglitaw ng isang bagong pull request o commit ay magti-trigger sa pagsusuri. Kung ang isang commit ay naglalaman ng mga error, ipahiwatig ito ni Buddy sa pahina ng kahilingan sa pull.

AppVeyor

Ang pag-set up ng AppVeyor ay katulad ng Buddy, dahil nangyayari ang lahat sa web interface at hindi na kailangang magdagdag ng *.yml file sa repository ng proyekto.

Pumunta tayo sa tab na Mga Setting sa pangkalahatang-ideya ng proyekto:

Mag-scroll pababa sa page na ito at paganahin ang pag-save ng cache para sa pagkolekta ng mga pull request:

Ngayon, pumunta tayo sa tab na Environment, kung saan tinukoy natin ang imahe para sa pagpupulong at ang mga kinakailangang variable ng kapaligiran:

Kung nabasa mo na ang mga nakaraang seksyon, pamilyar ka sa dalawang variable na ito − PVS_KEY и PVS_USERNAME. Kung hindi, hayaan mong ipaalala ko sa iyo na kailangan nilang i-verify ang lisensya ng PVS-Studio analyzer. Makikita natin silang muli sa mga script ng Bash sa hinaharap.

Sa parehong pahina sa ibaba ipinapahiwatig namin ang folder para sa pag-cache:

Kung hindi namin gagawin ito, susuriin namin ang buong proyekto sa halip na isang pares ng mga file, ngunit makukuha namin ang output mula sa tinukoy na mga file. Samakatuwid, mahalagang ipasok ang tamang pangalan ng direktoryo.

Ngayon ay oras na para subukan ang script. Buksan ang tab na Mga Pagsubok at piliin ang Script:

Kailangan mong i-paste ang sumusunod na code sa form na ito:

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

Bigyang-pansin natin ang sumusunod na bahagi ng code:

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

Ang medyo tiyak na pagtatalaga ng halaga ng pwd command sa isang variable na dapat mag-imbak ng default na halaga na ito ay tila kakaiba sa unang tingin, gayunpaman, ipapaliwanag ko ang lahat ngayon.

Habang sine-set up ang analyzer sa AppVeyor, nakatagpo ako ng kakaibang pag-uugali ng analyzer. Sa isang banda, ang lahat ay nagtrabaho nang tama, ngunit ang pagsusuri ay hindi nagsimula. Gumugol ako ng maraming oras na napansin na kami ay nasa /home/appveyor/projects/testcalc/ direktoryo, at ang analyzer ay sigurado na kami ay nasa /opt/appveyor/build-agent/. Pagkatapos ay napagtanto ko na ang $PWD variable ay namamalagi nang kaunti. Para sa kadahilanang ito, mano-mano kong na-update ang halaga nito bago simulan ang pagsusuri.

At pagkatapos ang lahat ay tulad ng dati:

Ngayon isaalang-alang ang sumusunod na fragment:

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

Dito natin nakukuha ang pagkakaiba sa pagitan ng mga sangay kung saan idineklara ang kahilingan sa paghila. Upang gawin ito kailangan namin ang mga sumusunod na variable ng kapaligiran:

$APPVEYOR_PULL_REQUEST_NUMBER — numero ng kahilingan sa paghila;
$APPVEYOR_REPO_NAME - user name at repository ng proyekto.

Konklusyon

Siyempre, hindi namin isinasaalang-alang ang lahat ng posibleng tuluy-tuloy na serbisyo sa pagsasama, gayunpaman, lahat sila ay may lubos na magkatulad na mga detalye ng pagpapatakbo sa bawat isa. Maliban sa pag-cache, ang bawat serbisyo ay gumagawa ng sarili nitong "bisikleta", kaya ang lahat ay palaging naiiba.

Sa isang lugar, tulad ng sa Travis-CI, gumagana nang walang kamali-mali ang ilang linya ng code at caching; sa isang lugar, tulad ng sa AppVeyor, kailangan mo lamang tukuyin ang folder sa mga setting; ngunit sa isang lugar kailangan mong lumikha ng mga natatanging key at subukang kumbinsihin ang system na bigyan ka ng pagkakataong i-overwrite ang naka-cache na fragment. Samakatuwid, kung gusto mong mag-set up ng pagsusuri ng mga kahilingan sa pag-pull sa isang tuluy-tuloy na serbisyo sa pagsasama na hindi tinalakay sa itaas, siguraduhin munang hindi ka magkakaroon ng mga problema sa pag-cache.

Salamat sa iyong atensyon. Kung may hindi gumana, huwag mag-atubiling sumulat sa amin sa suporta. Kami ay magpapayo at tutulong.

Kung nais mong ibahagi ang artikulong ito sa isang madla na nagsasalita ng Ingles, mangyaring gamitin ang link ng pagsasalin: Maxim Zvyagintsev. Pagsusuri ng mga commit at pull request sa Travis CI, Buddy at AppVeyor gamit ang PVS-Studio.

Pinagmulan: www.habr.com

Pagsusuri ng mga commit at pull request sa Travis CI, Buddy at AppVeyor gamit ang PVS-Studio