🥇Պարտավորությունների վերլուծություն և պահանջների վերլուծություն Travis CI-ում, Buddy-ում և AppVeyor-ում՝ օգտագործելով PVS-Studio

Linux-ի և macOS-ի C և C++ լեզուների PVS-Studio անալիզատորում, սկսած 7.04 տարբերակից, հայտնվել է թեստային տարբերակ՝ նշված ֆայլերի ցանկը ստուգելու համար: Օգտագործելով նոր ռեժիմը, դուք կարող եք կարգավորել անալիզատորը, որպեսզի ստուգի պարտավորությունները և պահանջները քաշի: Այս հոդվածը ձեզ կպատմի, թե ինչպես կարելի է ստուգել GitHub նախագծի փոփոխված ֆայլերի ցանկը այնպիսի հայտնի CI (Շարունակական ինտեգրում) համակարգերում, ինչպիսիք են Travis CI-ն, Buddy-ն և AppVeyor-ը:

Ֆայլերի ցուցակի ստուգման ռեժիմ

PVS- ստուդիա C, C++, C# և Java լեզուներով գրված ծրագրերի սկզբնական կոդի սխալներն ու հնարավոր խոցելիությունները հայտնաբերելու գործիք է։ Աշխատում է Windows-ի, Linux-ի և macOS-ի 64-բիթանոց համակարգերի վրա:

Linux-ի և macOS-ի համար PVS-Studio 7.04 տարբերակում հայտնվել է աղբյուրի ֆայլերի ցանկը ստուգելու ռեժիմ։ Սա աշխատում է այն նախագծերի համար, որոնց կառուցման համակարգը թույլ է տալիս ստեղծել ֆայլ compile_commands.json. Այն անհրաժեշտ է, որպեսզի անալիզատորը տեղեկատվություն կորզի նշված ֆայլերի կազմման մասին: Եթե ձեր կառուցման համակարգը չի աջակցում compile_commands.json ֆայլի ստեղծմանը, կարող եք փորձել ստեղծել այդպիսի ֆայլ՝ օգտագործելով կոմունալ ծրագիրը: Կրել.

Նաև ֆայլերի ցանկը ստուգելու ռեժիմը կարող է օգտագործվել կոմպիլյատորների գործարկումների հետքի հետքի հետ միասին (pvs-studio-analyzer trace): Դա անելու համար նախ պետք է իրականացնել նախագծի ամբողջական կառուցումը և հետևել դրան, որպեսզի անալիզատորը հավաքի ամբողջական տեղեկատվություն բոլոր ստուգվող ֆայլերի կոմպիլացիոն պարամետրերի մասին:

Այնուամենայնիվ, այս տարբերակն ունի մի զգալի թերություն. դուք կամ պետք է կատարեք ամբողջ նախագծի ամբողջական կառուցման հետքը ամեն անգամ, երբ այն գործարկեք, ինչն ինքնին հակասում է պարտավորությունների արագ ստուգման գաղափարին: Կամ, եթե դուք ինքնին քեշում եք հետագծման արդյունքը, անալիզատորի հետագա գործարկումները կարող են թերի լինել, եթե աղբյուրի ֆայլերի կախվածության կառուցվածքը փոխվի հետագծումից հետո (օրինակ, աղբյուրի ֆայլերից մեկին ավելացվի նոր #include):

Հետևաբար, մենք խորհուրդ չենք տալիս օգտագործել ֆայլերի ցուցակի ստուգման ռեժիմը հետագծման գրանցամատյանով` պարտավորությունները ստուգելու կամ պահանջները քաշելու համար: Այն դեպքում, երբ դուք կարող եք կատարել աճող կառուցում, երբ ստուգում եք կատարումը, մտածեք ռեժիմի օգտագործման մասին աստիճանական վերլուծություն.

Վերլուծության համար աղբյուրի ֆայլերի ցանկը պահվում է տեքստային ֆայլում և փոխանցվում է անալիզատորին՝ օգտագործելով պարամետրը -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.

Իհարկե, հնարավոր կլիներ ստուգել դրանց միաձուլման ամբողջ արդյունքը, բայց դա չափազանց ժամանակատար և չարդարացված կլիներ, քանի որ ընդամենը մի քանի ֆայլ է փոխվել։ Ուստի ավելի արդյունավետ է վերլուծել միայն փոխվածները։

Դա անելու համար մենք ստանում ենք ճյուղերի միջև տարբերությունը, լինելով այն մասնաճյուղի գլխում, որտեղից մենք ցանկանում ենք միաձուլվել վարպետի.

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 (--նշել-նախազգուշացումներ) Եթե կա առնվազն մեկ անալիզատորի նախազգուշացում, կոմունալ ծառայության վերադարձի կոդը լոգ-փոխարկիչ կփոխվի 2-ի, որն իր հերթին կտեղեկացնի CI ծառայությանը պոտենցիալ սխալների առկայության մասին pull request ֆայլերում:

Թրևիս CI

Կազմաձևը կատարվում է որպես ֆայլ .travis.yml. Հարմարության համար խորհուրդ եմ տալիս ամեն ինչ դնել առանձին bash սցենարի մեջ՝ ֆունկցիաներով, որոնք կկանչվեն ֆայլից .travis.yml (bash script_name.sh function_name).

Մենք կավելացնենք անհրաժեշտ կոդը սցենարին ժամը ուժեղ հարվածել, այս կերպ մենք ավելի շատ ֆունկցիոնալություն կստանանք։ Բաժնում տեղադրել գրենք հետևյալը.

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 build.

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-ի բաժինը, ապա այս կոդը արդեն ծանոթ է ձեզ, սակայն այժմ կա նոր քայլ.

Փաստն այն է, որ այժմ մենք վերլուծում ենք ոչ թե միաձուլման արդյունքը, այլ այն մասնաճյուղի ՂԵԿԱՎԱՐԸ, որից կատարվում է ձգման հարցումը.

Այսպիսով, մենք պայմանական պարտավորության մեջ ենք 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 - քաշելու խնդրանքի համարը;
$BUDDY_REPO_SLUG - օգտվողի անվան և պահեստի համադրություն (օրինակ, առավելագույնը / թեստ):

Այժմ եկեք պահպանենք փոփոխությունները՝ օգտագործելով ստորև բերված կոճակը և միացնենք ձգման հարցումի վերլուծությունը.

Ի տարբերություն Travis CI-ի, մենք հստակեցնելու կարիք չունենք .pvs-studio քեշավորման համար, քանի որ Բադին ավտոմատ կերպով պահում է բոլոր ֆայլերը հետագա գործարկումների համար: Հետևաբար, վերջին բանը, որ մնում է PVS-Studio-ի մուտքի և գաղտնաբառի պահպանումն է Buddy-ում: Փոփոխությունները պահպանելուց հետո մենք կվերադառնանք խողովակաշարին: Մենք պետք է գնանք պարամետրերի փոփոխականներ և ավելացնենք մուտք և բանալին PVS-Studio-ի համար.

Սրանից հետո նոր ձգման խնդրանքի կամ պարտավորության հայտնվելը կսկսի վերանայումը: Եթե commit-ը պարունակում է սխալներ, Բադին դա կնշի pull-ի հարցումների էջում:

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-ում.

Source: www.habr.com

Պարտավորությունների և պահանջների վերլուծություն Travis CI-ում, Buddy-ում և AppVeyor-ում PVS-Studio-ում