ვალდებულებების ანალიზი და ამოღებული მოთხოვნები 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-ზე.

Linux-ისა და macOS-ისთვის PVS-Studio 7.04 ვერსიაში გამოჩნდა წყარო ფაილების სიის შემოწმების რეჟიმი. ეს მუშაობს პროექტებისთვის, რომელთა build სისტემა საშუალებას გაძლევთ შექმნათ ფაილი compile_commands.json. საჭიროა ანალიზატორისთვის ინფორმაციის ამოღება მითითებული ფაილების შედგენის შესახებ. თუ თქვენი build სისტემა არ უჭერს მხარს compile_commands.json ფაილის გენერირებას, შეგიძლიათ სცადოთ ასეთი ფაილის გენერირება უტილიტის გამოყენებით. Bear.

ასევე, ფაილების სიის შემოწმების რეჟიმი შეიძლება გამოყენებულ იქნას შემდგენელის გაშვების სტრაის კვალის ჟურნალთან ერთად (pvs-studio-analyzer trace). ამისათვის თქვენ ჯერ უნდა შეასრულოთ პროექტის სრული კონსტრუქცია და თვალყური ადევნოთ მას ისე, რომ ანალიზატორი შეაგროვოს სრული ინფორმაცია ყველა შემოწმებული ფაილის კომპილაციის პარამეტრების შესახებ.

თუმცა, ამ ვარიანტს აქვს მნიშვნელოვანი ნაკლი - თქვენ ან მოგიწევთ შეასრულოთ მთელი პროექტის სრული ბილდაციის კვალი ყოველ ჯერზე მისი გაშვებისას, რაც თავისთავად ეწინააღმდეგება ჩადენის სწრაფი შემოწმების იდეას. ან, თუ თქვენ ქეშირებთ კვალის შედეგს, ანალიზატორის შემდგომი გაშვებები შეიძლება იყოს არასრული, თუ წყაროს ფაილების დამოკიდებულების სტრუქტურა იცვლება ტრასის შემდეგ (მაგალითად, ახალი #include დაემატება ერთ-ერთ წყაროს ფაილს).

აქედან გამომდინარე, ჩვენ არ გირჩევთ გამოიყენოთ ფაილების სიის შემოწმების რეჟიმი კვალის ჟურნალით, რათა შეამოწმოთ ვალდებულებები ან მოთხოვნების ამოღება. იმ შემთხვევაში, თუ თქვენ შეძლებთ დამატებითი აშენების გაკეთებას commit-ის შემოწმებისას, განიხილეთ რეჟიმის გამოყენება დამატებითი ანალიზი.

ანალიზისთვის წყაროს ფაილების სია ინახება ტექსტურ ფაილში და გადაეცემა ანალიზატორს პარამეტრის გამოყენებით -S:

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

ეს ფაილი განსაზღვრავს ფაილების შედარებით ან აბსოლუტურ ბილიკებს და ყოველი ახალი ფაილი უნდა იყოს ახალ ხაზზე. დასაშვებია არა მხოლოდ ფაილის სახელების, არამედ სხვადასხვა ტექსტის მითითება ანალიზისთვის. ანალიზატორი დაინახავს, ​​რომ ეს არ არის ფაილი და უგულებელყოფს ხაზს. ეს შეიძლება სასარგებლო იყოს კომენტარისთვის, თუ ფაილები მითითებულია ხელით. თუმცა, ხშირად ფაილების სია წარმოიქმნება CI-ში ანალიზის დროს, მაგალითად, ეს შეიძლება იყოს ფაილები commit ან pull-ის მოთხოვნიდან.

ახლა, ამ რეჟიმის გამოყენებით, შეგიძლიათ სწრაფად შეამოწმოთ ახალი კოდი, სანამ ის მოხვდება განვითარების მთავარ ფილიალში. იმის უზრუნველსაყოფად, რომ სკანირების სისტემა პასუხობს ანალიზატორის გაფრთხილებებს, უტილიტა ბლოგ-კონვერტორი დროშა დაემატა -- მიუთითეთ-გაფრთხილება:

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

ამ დროშით, კონვერტორი დააბრუნებს არა-ნულოვან კოდს, თუ არის გაფრთხილებები ანალიზატორის ანგარიშში. დაბრუნების კოდის გამოყენებით, თქვენ შეგიძლიათ დაბლოკოთ წინასწარი ჩართვის, ჩადენა ან მოთხოვნის ამოღება და გენერირებული ანალიზატორის ანგარიშის ჩვენება, გაზიარება ან გაგზავნა შესაძლებელია ელექტრონული ფოსტით.

Შენიშვნა. როდესაც პირველად დაიწყებთ ფაილების სიის ანალიზს, მთელი პროექტი გაანალიზდება, რადგან ანალიზატორს სჭირდება სათაურის ფაილებზე პროექტის წყაროს ფაილების დამოკიდებულების ფაილის გენერირება. ეს არის C და C++ ფაილების ანალიზის ფუნქცია. მომავალში, დამოკიდებულების ფაილის ქეშირება შესაძლებელია და ის ავტომატურად განახლდება ანალიზატორის მიერ. commit-ების შემოწმების უპირატესობა ფაილების სიის შემოწმების რეჟიმის გამოყენებისას, დამატებითი ანალიზის რეჟიმის გამოყენებასთან შედარებით არის ის, რომ საჭიროა მხოლოდ ამ ფაილის ქეშირება და არა ობიექტის ფაილების.

მოზიდვის მოთხოვნის ანალიზის ზოგადი პრინციპები

მთელი პროექტის ანალიზს დიდი დრო სჭირდება, ამიტომ აზრი აქვს მისი მხოლოდ გარკვეული ნაწილის შემოწმებას. პრობლემა ის არის, რომ თქვენ უნდა გამოყოთ ახალი ფაილები პროექტის დანარჩენი ფაილებისგან.

მოდით შევხედოთ commit ხის მაგალითს ორი ტოტით:

წარმოვიდგინოთ ეს ვალდებულება A1 შეიცავს საკმაოდ დიდ რაოდენობას, რომელიც უკვე გამოცდილია. ცოტა ადრე ჩვენ გავაკეთეთ ფილიალი კომიტიდან A1 და შეცვალა რამდენიმე ფაილი.

თქვენ, რა თქმა უნდა, შენიშნეთ ეს მას შემდეგ A1 მოხდა კიდევ ორი ​​ვალდებულება, მაგრამ ეს ასევე იყო სხვა ფილიალების შერწყმა, რადგან ჩვენ არ ვასრულებთ ვალდებულებას სამაგისტრო. ახლა კი დადგა დრო, როცა ცხელი წერტილი მზადაა. ამიტომ გაჩნდა შერწყმის მოთხოვნა B3 и A3.

რა თქმა უნდა, შესაძლებელი იქნებოდა მათი შერწყმის მთელი შედეგის შემოწმება, მაგრამ ეს ძალიან შრომატევადი და გაუმართლებელი იქნებოდა, რადგან მხოლოდ რამდენიმე ფაილი შეიცვალა. ამიტომ უფრო ეფექტურია მხოლოდ შეცვლილთა ანალიზი.

ამისათვის ჩვენ ვიღებთ განსხვავებას ფილიალებს შორის, იმ ფილიალის HEAD-ში, საიდანაც გვინდა შერწყმა მასტერში:

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

ეს ბრძანება ჩამოთვლის შეცდომებს უფროსი (სტანდარტული შეცდომის შეტყობინების გამომავალი).

მხოლოდ ახლა გვჭირდება არა მხოლოდ შეცდომების ჩვენება, არამედ შეკრების და ტესტირების სერვისის ინფორმირება პრობლემების არსებობის შესახებ. ამ მიზნით, კონვერტორს დაემატა დროშა -W (-- მიუთითეთ-გაფრთხილება). თუ არის მინიმუმ ერთი ანალიზატორის გაფრთხილება, კომუნალური დაბრუნების კოდი ბლოგ-კონვერტორი შეიცვლება 2-ით, რაც თავის მხრივ აცნობებს CI სერვისს პოტენციური შეცდომების არსებობის შესახებ pull-ის მოთხოვნის ფაილებში.

ტრევის CI

კონფიგურაცია ხდება ფაილის სახით .travis.yml. მოხერხებულობისთვის, გირჩევთ, ყველაფერი ჩადოთ ცალკე bash სკრიპტში ფუნქციებით, რომლებიც გამოიძახება ფაილიდან .travis.yml (bash script_name.sh ფუნქცია_სახელი).

ჩვენ დავამატებთ საჭირო კოდს სკრიპტს მისამართზე Bash, ამ გზით ჩვენ მივიღებთ მეტ ფუნქციონირებას. განყოფილებაში ინსტალაცია დავწეროთ შემდეგი:

install:
  - bash .travis.sh travis_install

თუ რაიმე ინსტრუქცია გქონდათ, შეგიძლიათ გადაიტანოთ ისინი სკრიპტში, დეფისების მოხსნით.

მოდით გავხსნათ ფაილი .ტრევის.შ და დაამატეთ ანალიზატორის პარამეტრი ფუნქციას 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 ინახავს გაყვანის მოთხოვნის ნომერს ან ყალბითუ ეს ჩვეულებრივი ფილიალია;
• $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. ეს დირექტორია ინახავს ანალიზის შემდეგ შეგროვებულ სხვადასხვა მონაცემებს, რაც მნიშვნელოვნად დააჩქარებს ფაილების სიის ანალიზის ან დამატებითი ანალიზის შემდგომ გაშვებას. თუ ეს არ გაკეთებულა, მაშინ ანალიზატორი რეალურად აანალიზებს ყველა ფაილს ყოველ ჯერზე.

Buddy

Travis CI-ის მსგავსად, Buddy უზრუნველყოფს 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_EXECUTION_PULL_REQEUST_NO - pull მოთხოვნის ნომერი;
• $BUDDY_REPO_SLUG - მომხმარებლის სახელისა და საცავის კომბინაცია (მაგალითად, max/test).

ახლა მოდით შევინახოთ ცვლილებები ქვემოთ მოცემული ღილაკის გამოყენებით და ჩავრთოთ მოთხოვნის ანალიზი:

Travis CI-ისგან განსხვავებით, ჩვენ არ გვჭირდება დაკონკრეტება .pvs-studio ქეშირებისთვის, რადგან ბადი ავტომატურად ინახავს ყველა ფაილს შემდგომ გაშვებისთვის. მაშასადამე, ბოლო რაც დარჩა არის PVS-Studio-ს შესვლისა და პაროლის შენახვა Buddy-ში. ცვლილებების შენახვის შემდეგ, ჩვენ დავბრუნდებით Pipeline-ზე. ჩვენ უნდა გადავიდეთ ცვლადების დაყენებაზე და PVS-Studio-სთვის შესვლისა და გასაღების დამატებაზე:

ამის შემდეგ, ახალი მოთხოვნის ან ვალდებულების გამოჩენა გამოიწვევს განხილვას. თუ ჩადენა შეიცავს შეცდომებს, ბადი ამას მიუთითებს გაყვანის მოთხოვნის გვერდზე.

AppVeyor

AppVeyor-ის დაყენება ბადის მსგავსია, რადგან ყველაფერი ხდება ვებ ინტერფეისში და არ არის საჭირო *.yml ფაილის დამატება პროექტის საცავში.

მოდით გადავიდეთ პარამეტრების ჩანართზე პროექტის მიმოხილვაში:

მოდით გადავიდეთ ამ გვერდის ქვემოთ და ჩავრთოთ ქეშის შენახვა მოთხოვნის შეგროვებისთვის:

ახლა გადავიდეთ Environment ჩანართზე, სადაც ვაზუსტებთ ასამბლეის სურათს და გარემოს აუცილებელ ცვლადებს:

თუ წაიკითხეთ წინა სექციები, თქვენ კარგად იცნობთ ამ ორ ცვლადს - 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"`

მასში ვიღებთ განსხვავებას იმ ტოტებს შორის, რომლებზეც გამოცხადებულია pull მოთხოვნა. ამისათვის ჩვენ გვჭირდება შემდეგი გარემოს ცვლადები:

• $APPVEYOR_PULL_REQUEST_NUMBER — გაყვანის მოთხოვნის ნომერი;
• $APPVEYOR_REPO_NAME - მომხმარებლის სახელი და პროექტის საცავი.

დასკვნა

რა თქმა უნდა, ჩვენ არ განვიხილეთ ყველა შესაძლო უწყვეტი ინტეგრაციის სერვისი, თუმცა, მათ ყველას აქვთ ერთმანეთის უკიდურესად მსგავსი ოპერაციული სპეციფიკა. ქეშირების გარდა, თითოეული სერვისი აწარმოებს საკუთარ „ველოსიპედს“, ამიტომ ყველაფერი ყოველთვის განსხვავებულია.

სადღაც, როგორც Travis-CI-ში, კოდის და ქეშირების რამდენიმე ხაზი მუშაობს უნაკლოდ; სადღაც, როგორც AppVeyor-ში, თქვენ უბრალოდ უნდა მიუთითოთ საქაღალდე პარამეტრებში; მაგრამ სადღაც თქვენ უნდა შექმნათ უნიკალური გასაღებები და შეეცადოთ დაარწმუნოთ სისტემა, რომ მოგცეთ შესაძლებლობა გადაწეროთ ქეშირებული ფრაგმენტი. ამიტომ, თუ გსურთ დააყენოთ მოთხოვნის ანალიზი უწყვეტი ინტეგრაციის სერვისზე, რომელიც ზემოთ არ იყო განხილული, მაშინ ჯერ დარწმუნდით, რომ არ შეგექმნებათ პრობლემები ქეშირებასთან დაკავშირებით.

Გმადლობთ ყურადღებისთვის. თუ რამე არ გამოვიდა, მოგერიდებათ მოგვწეროთ მისამართზე მხარდაჭერა. ჩვენ გაგიწევთ რჩევას და დაგეხმარებით.

თუ გსურთ გაუზიაროთ ეს სტატია ინგლისურენოვან აუდიტორიას, გთხოვთ, გამოიყენოთ თარგმანის ბმული: მაქსიმ ზვიაგინცევი. ვალდებულებების ანალიზი და ამოღებული მოთხოვნები Travis CI-ში, Buddy-სა და AppVeyor-ში PVS-Studio-ს გამოყენებით.

წყარო: www.habr.com