पीवीएस-स्टूडियो का उपयोग करके ट्रैविस सीआई, बडी और एपवेयर में कमिट और पुल अनुरोधों का विश्लेषण

7.04 संस्करण से शुरू, लिनक्स और मैकओएस पर सी और सी ++ भाषाओं के लिए पीवीएस-स्टूडियो विश्लेषक निर्दिष्ट फ़ाइलों की सूची की जांच की सुविधा प्रदान करता है। नए मोड का उपयोग करके, आप कमिटर्स की जांच करने और अनुरोधों को खींचने के लिए विश्लेषक को कॉन्फ़िगर कर सकते हैं। इस लेख में कुछ लोकप्रिय सीआई (कंटीन्यूअस इंटीग्रेशन) सिस्टम में GitHub प्रोजेक्ट से कुछ संशोधित फ़ाइलों की जाँच को शामिल किया गया है, जैसे ट्रैविस CI, बडी और अप्पेयर।

फाइलों की सूची जांचने का तरीका

पीवीएस-स्टूडियो एक उपकरण है जिसे सी, सी ++, सी # और जावा में लिखे गए कार्यक्रमों के स्रोत कोड में त्रुटियों और संभावित कमजोरियों का पता लगाने के लिए डिज़ाइन किया गया है। विंडोज, लिनक्स और मैकओएस पर 64-बिट सिस्टम में काम करता है।

लिनक्स और मैकओएस के लिए पीवीएस-स्टूडियो 7.04 संस्करण में अब फाइलों की सूची की जांच करने का तरीका है। यह उन परियोजनाओं के लिए काम करता है, जिनकी निर्माण प्रणाली compile_commands.json फ़ाइल बनाने की अनुमति देती है। विश्लेषक को कुछ फाइलों के संकलन के बारे में जानकारी प्राप्त करने के लिए इसकी आवश्यकता होती है। यदि आपका बिल्ड सिस्टम compile_commands.json फ़ाइल की पीढ़ी का समर्थन नहीं करता है, तो आप Bear उपयोगिता का उपयोग करके ऐसी फ़ाइल बनाने का प्रयास कर सकते हैं।

स्टाइल्स (pvs-studio-विश्लेषक ट्रेस) द्वारा उत्पन्न कंपाइलर रन ट्रेसिंग लॉग के साथ फ़ाइलों की सूची की जांच करने का यह तरीका भी इस्तेमाल किया जा सकता है। ऐसा करने के लिए, पहले आपको एक पूर्ण प्रोजेक्ट बिल्ड को पूरा करने और इसे ट्रेस करने की आवश्यकता है ताकि विश्लेषक सभी जाँच की गई फ़ाइलों के संकलन मापदंडों के बारे में पूरी जानकारी एकत्र कर सके।

हालांकि, इस विकल्प में एक महत्वपूर्ण कमी है - आपको या तो प्रत्येक रन के साथ पूरी परियोजना का पूर्ण निर्माण अनुरेखण करना होगा, जो एक त्वरित प्रतिबद्ध जांच के विचार के खिलाफ जाता है। या यदि आप अनुरेखण परिणाम को कैश करते हैं, तो बाद की विश्लेषक रन मामले में अधूरी हो सकती है यदि स्रोत फ़ाइलों की संरचना को बदलने के बाद निर्भरता में बदलाव होता है (उदाहरण के लिए, स्रोत फ़ाइलों में से एक में एक नया #include जोड़ा जाता है)।

इसलिए, हम अनुरोधों की जांच करने या अनुरोधों को खींचने के लिए ट्रेसिंग लॉग वाली फ़ाइलों की सूची की जाँच करने के तरीके का उपयोग करने की अनुशंसा नहीं करते हैं। यदि आप एक कमिटमेंट बनाते समय एक वृद्धिशील निर्माण कर सकते हैं, तो वृद्धिशील विश्लेषण मोड का उपयोग करने पर विचार करें।

विश्लेषण के लिए स्रोत फ़ाइलों की सूची को टेक्स्ट फ़ाइल में सहेजा जाता है और -S पैरामीटर का उपयोग करके विश्लेषक को पास किया जाता है:

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

इस फ़ाइल में उन फ़ाइलों के सापेक्ष और निरपेक्ष पथ होते हैं जहाँ प्रत्येक नई फ़ाइल एक नई पंक्ति में आती है। आप विश्लेषण और विभिन्न पाठ के लिए दोनों फ़ाइल नाम निर्दिष्ट कर सकते हैं। पाठ के लिए, विश्लेषक ध्यान देगा कि यह एक फ़ाइल नाम नहीं है और लाइन को अनदेखा करेगा। यह टिप्पणी करने के लिए उपयोगी हो सकता है कि क्या फाइलें मैन्युअल रूप से निर्दिष्ट हैं। हालांकि, अक्सर सीआई विश्लेषण के दौरान फाइलों की सूची उत्पन्न होगी, उदाहरण के लिए, यह एक कमिट या पुल अनुरोध से फाइलें हो सकती है।

अब इस मोड का उपयोग करके आप मुख्य विकास शाखा में आने से पहले नए कोड को जल्दी से देख सकते हैं। - पॉन्ड-कनवर्टर यूटिलिटी में इंडिनेट-वॉर्निंग फ्लैग को जोड़ा गया था ताकि चेक सिस्टम ने एनालाइज़र चेतावनियों की उपस्थिति का जवाब दिया।

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

इस ध्वज के साथ, कनवर्टर गैर-शून्य कोड लौटाएगा यदि विश्लेषक रिपोर्ट में चेतावनी है। आप पूर्व प्रतिबद्ध हुक को रोक सकते हैं, अनुरोध कर सकते हैं या अनुरोध कर सकते हैं और उत्पन्न विश्लेषक रिपोर्ट को प्रदर्शित कर सकते हैं, साझा कर सकते हैं या इसे डाक से भेज सकते हैं।

नोट। फ़ाइलों की सूची के पहले विश्लेषण के दौरान, पूरे प्रोजेक्ट की जाँच की जाएगी, क्योंकि विश्लेषक को हेडर फ़ाइलों से प्रोजेक्ट स्रोत फ़ाइलों की निर्भरता वाली फ़ाइल जनरेट करनी होगी। यह C और C ++ फ़ाइलों के विश्लेषण की ख़ासियत है। भविष्य में, यह निर्भरता फ़ाइल कैश की जा सकती है और विश्लेषक द्वारा स्वचालित रूप से अपडेट की जाएगी। वृद्धिशील विश्लेषण मोड पर फ़ाइलों की सूची की जाँच करने के मोड का उपयोग करके जांच करने का लाभ यह है कि आपको केवल इस फ़ाइल को कैश करना है, न कि ऑब्जेक्ट फ़ाइलों को।

पुल अनुरोध विश्लेषण के सामान्य सिद्धांत

पूरे प्रोजेक्ट विश्लेषण में काफी समय लगता है, इसलिए इसका केवल एक हिस्सा जांचना समझ में आता है। समस्या यह है कि आपको नई फ़ाइलों को प्रोजेक्ट फ़ाइलों के बाकी हिस्सों से अलग करने की आवश्यकता है।

आइए एक दो-शाखा प्रतिबद्ध पेड़ के उदाहरण को देखें:

कल्पना करें कि A1 कमिट में बहुत बड़ी मात्रा में कोड है जो पहले ही चेक किया जा चुका है। पहले, हमने A1 कमिट से एक शाखा बनाई है और कुछ फाइलें बदली हैं।

बेशक, आपने देखा है कि A1 के बाद दो अन्य कमिट हुए, और दो अन्य शाखाएं मर्ज हुईं, जैसा कि हम मास्टर में नहीं करते हैं। यहां वह क्षण आता है जब हॉटफिक्स तैयार होता है। इसलिए हमें बी 3 और ए 3 विलय के लिए एक पुल अनुरोध मिला।

हम उनके विलय के परिणाम की जांच कर सकते हैं, लेकिन यह बहुत लंबा और अनुचित होगा, क्योंकि केवल कुछ फाइलों को संशोधित किया गया है। इसलिए, केवल परिवर्तित लोगों का विश्लेषण करना अधिक कुशल है।

ऐसा करने के लिए, हम शाखाओं के बीच अंतर प्राप्त करेंगे, शाखा के HEAD में होने से, जिसमें से हम मास्टर में विलय करना चाहते हैं:

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

हम बाद में विस्तार से $ MERGE_BASE पर विचार करेंगे। तथ्य यह है कि प्रत्येक सीआई सेवा मर्ज बेस पर आवश्यक जानकारी प्रदान नहीं करती है, इसलिए हर बार हमें इस डेटा को प्राप्त करने के नए तरीकों के बारे में सोचना होगा। यह वर्णित वेब सेवाओं में से प्रत्येक के लिए नीचे दिए गए विवरणों पर विचार किया जाएगा।

इसलिए हमें शाखाओं के बीच अंतर मिला, जो संशोधित फ़ाइलों के नामों की सूची है। अब हमें विश्लेषक को यह .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 में बदल जाएगा, जो बदले में सीआई सेवा को पुल अनुरोध की फाइलों में संभावित त्रुटियों के बारे में रिपोर्ट करेगा।

ट्रैविस सी.आई.

कॉन्फ़िगरेशन .travis.yml फ़ाइल के रूप में किया जाता है। सुविधा के लिए, मैं आपको पीवीएस-स्टूडियो से संबंधित सभी कमांडों को अलग-अलग बैश स्क्रिप्ट में फ़ंक्शंस के साथ अलग करने की सलाह देता हूं जो फ़ाइल .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 

और बैश स्क्रिप्ट में:

 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_PULL_REQUEST एक नियमित शाखा होने पर पुल अनुरोध संख्या या गलत संग्रहीत करता है;
• $ TRAVIS_REPO_SLUG प्रोजेक्ट रिपॉजिटरी के नाम को संग्रहीत करता है।

यहां इस फ़ंक्शन का संचालन एल्गोरिथ्म है:

ट्रैविस सीआई कोड वापस करने का जवाब देता है, इसलिए चेतावनियों की उपस्थिति सेवा को त्रुटियों वाले के रूप में चिह्नित करने के लिए रिपोर्ट करेगी।

अब कोड की इस पंक्ति पर एक नज़र डालते हैं:

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

तथ्य यह है कि ट्रैविस सीआई स्वचालित रूप से शाखाओं का विलय करता है जब एक पुल अनुरोध का विश्लेषण करता है:

इसलिए हम A4 का विश्लेषण करते हैं, B3-> A3 का नहीं । इस ख़ासियत के कारण, हमें A3 के साथ अंतर का मूल्यांकन करने की आवश्यकता है, जो मूल से शाखा का प्रमुख है।

एक महत्वपूर्ण विवरण रहता है - संकलित अनुवाद इकाइयों (* .c, * .cc, * .cpp और अन्य) से हेडर फ़ाइलों की निर्भरता को कैशिंग। विश्लेषक फ़ाइलों की सूची की जाँच के मोड में पहले रन के दौरान इन निर्भरताओं का मूल्यांकन करता है और फिर उन्हें .PVS-Studio निर्देशिका में संग्रहीत करता है। ट्रैविस सीआई रिपॉजिटरी को कैशिंग करने की अनुमति देता है, इसलिए हम .PVS-Studio / डायरेक्टरी में डेटा सेव करेंगे:

 cache: directories: - .PVS-Studio/ 

इस कोड को .travis.yml फ़ाइल में जोड़ा जाना है: यह निर्देशिका विभिन्न डेटा संग्रहीत करती है, विश्लेषण के बाद एकत्र की जाती है। यह डेटा फ़ाइलों की सूची विश्लेषण या वृद्धिशील विश्लेषण के बाद के रन को काफी तेज करता है। यदि आप ऐसा नहीं करते हैं, तो विश्लेषक हर बार सभी फाइलों का विश्लेषण करेगा।

बडी

ट्रैविस सीआई, बडी के समान ही आपको गिटहब से परियोजनाओं को स्वचालित रूप से बनाने और परीक्षण करने में सक्षम बनाता है। ट्रैविस सीआई के विपरीत, यह वेब इंटरफेस में कॉन्फ़िगर किया गया है (बैश समर्थन उपलब्ध है), इसलिए परियोजना में कॉन्फ़िगरेशन फ़ाइलों को संग्रहीत करने की कोई आवश्यकता नहीं है।

सबसे पहले, हमें पाइपलाइन में एक नया कदम जोड़ने की जरूरत है:

आइए परियोजना के निर्माण के लिए उपयोग किए गए कंपाइलर को निर्दिष्ट करें। इस कदम के दौरान स्थापित डॉकटर कंटेनर पर ध्यान दें। उदाहरण के लिए, GCC के लिए एक विशेष कंटेनर है:

अब पीवीएस-स्टूडियो और आवश्यक उपयोगिताओं को स्थापित करें:

निम्नलिखित पंक्तियों को संपादक में जोड़ें:

 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 

आइए रन टैब (पहले आइकन) पर जाएं और निम्नलिखित कोड को उपयुक्त संपादक फ़ील्ड में जोड़ें:

 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:

तो हम एक बी 3 कमिट में हैं और हमें ए 3 के साथ अंतर प्राप्त करने की आवश्यकता है:

 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 - एक उपयोगकर्ता नाम और एक रिपॉजिटरी का संयोजन (उदाहरण के लिए, अधिकतम / परीक्षण)।

अब नीचे दिए गए बटन का उपयोग करते हुए परिवर्तनों को बचाएं और पुल अनुरोध विश्लेषण को सक्षम करें:

ट्रैविस सीआई के विपरीत, हमें कैशिंग के लिए .pvs-स्टूडियो को निर्दिष्ट नहीं करना है, क्योंकि बडी स्वचालित रूप से बाद की रनों की सभी फाइलों को कैश करता है। तो आखिरी चीज बडी में पीवीएस-स्टूडियो के लिए लॉगिन और पासवर्ड को सहेजना है। परिवर्तनों को सहेजने के बाद हम पाइपलाइन में वापस आएंगे। हमें चर स्थापित करने के लिए आगे बढ़ना है और पीवीएस-स्टूडियो के लिए लॉगिन और कुंजी सम्मिलित करना है:

इसके बाद, हर नए पुल अनुरोध या प्रतिबद्ध के साथ एक चेक शुरू होगा। यदि किसी प्रतिबद्ध में त्रुटियां हैं, तो बडी इसे पुल अनुरोध पृष्ठ पर इंगित करेगा।

AppVeyor

AppVeyor सेटिंग बडी के समान है, क्योंकि यह सब वेब इंटरफेस में होता है और प्रोजेक्ट रिपॉजिटरी में * .yml फाइल को जोड़ने की कोई आवश्यकता नहीं है।

परियोजना समीक्षा में सेटिंग टैब पर जाएं:

इस पृष्ठ को नीचे स्क्रॉल करें और पुल निर्माण अनुरोध के लिए कैश बचत को सक्षम करें:

अब पर्यावरण टैब पर चलते हैं, जहां हम निर्माण और आवश्यक पर्यावरण चर के लिए छवि निर्दिष्ट करेंगे:

यदि आपने पिछले अनुभाग पढ़े हैं, तो आप पहले से ही इन दो चर - PVS_KEY और PVS_USERNAME से परिचित हैं। यदि नहीं, तो मैं आपको याद दिला दूं कि उन्हें PVS-Studio विश्लेषक लाइसेंस की जाँच के लिए आवश्यक है। भविष्य में, हम उन्हें बैश लिपियों में फिर से मिलेंगे।

नीचे एक ही पृष्ठ पर, आइए कैश फोल्डर निर्दिष्ट करें:

यदि हम ऐसा नहीं करते हैं, तो हम एक दो फाइलों के बजाय पूरे प्रोजेक्ट का विश्लेषण करेंगे, लेकिन निर्दिष्ट फ़ाइलों के लिए आउटपुट प्राप्त करेंगे। इसलिए रिपॉजिटरी का सही नाम दर्ज करना महत्वपूर्ण है।

अब चेकिंग स्क्रिप्ट का समय आ गया है। टेस्ट टैब खोलें और स्क्रिप्ट चुनें:

निम्न कोड को इस रूप में डाला जाना चाहिए:

 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 में विश्लेषक की स्थापना करते समय, मैं अत्यधिक अजीब विश्लेषक व्यवहार पर ठोकर खाई। एक ओर, सब कुछ सही ढंग से काम किया, लेकिन विश्लेषण शुरू नहीं हुआ। यह देखने में बहुत समय लग गया कि हम / होम / ऐपवॉयर / प्रोजेक्ट्स / टेस्टक्लेक / डायरेक्टरी में थे, जबकि एनालाइज़र को यह सुनिश्चित था कि हम / ऑप्ट / ऐपवायर / बिल्ड-एजेंट / में थे। उस पल मुझे एहसास हुआ कि $ पीडब्ल्यूडी चर धोखेबाज है। इस कारण से, मैंने विश्लेषण चलाने से पहले मैन्युअल रूप से इसके मूल्य को नवीनीकृत किया।

आगे की कार्रवाई का क्रम पहले जैसा था:

अब इस टुकड़े पर एक नज़र डालें:

 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 - उपयोगकर्ता नाम और परियोजना भंडार।

निष्कर्ष

खैर, हमने सभी संभव निरंतर एकीकरण सेवाओं पर विचार नहीं किया है, हालांकि, सभी के पास समान परिचालन बारीकियां हैं। लेकिन कैशिंग के लिए, प्रत्येक सेवा अपने स्वयं के पहिया को फिर से स्थापित करती है, इसलिए यह हमेशा अलग होता है।

कुछ मामलों में (ट्रैविस-सीआई के रूप में) यह कोड लाइनों की एक जोड़ी लेता है - और कैशिंग त्रुटिपूर्ण रूप से काम करता है। अन्य मामलों में (AppVeyor के रूप में), आपको बस सेटिंग्स में निर्देशिका निर्दिष्ट करना होगा। लेकिन कुछ सेवाएं हैं, जहां आपको विशेष कुंजी बनाने की आवश्यकता है और सिस्टम को समझाने का प्रयास करने के लिए आपको कैश्ड टुकड़े को फिर से लिखने का मौका देना चाहिए। इसलिए, यदि आप निरंतर एकीकरण सेवा पर पुल अनुरोध विश्लेषण को कॉन्फ़िगर करना चाहते हैं, जिसे ऊपर नहीं माना गया है, तो पहले, सुनिश्चित करें कि आपको कैशिंग की समस्या नहीं होगी।

आपका ध्यान के लिए धन्यवाद। यदि कुछ काम नहीं करता है, तो आप सुरक्षित रूप से हमारे समर्थन को लिख सकते हैं। हम आपको संकेत देंगे और मदद करेंगे।