لینکس اور میک او ایس پر C اور C++ زبانوں کے لیے PVS-Studio تجزیہ کار میں، ورژن 7.04 سے شروع ہو کر، مخصوص فائلوں کی فہرست کو چیک کرنے کے لیے ایک ٹیسٹ آپشن ظاہر ہوا ہے۔ نئے موڈ کا استعمال کرتے ہوئے، آپ تجزیہ کار کو کمٹ چیک کرنے اور درخواستوں کو کھینچنے کے لیے تشکیل دے سکتے ہیں۔ یہ مضمون آپ کو بتائے گا کہ گٹ ہب پروجیکٹ کی تبدیل شدہ فائلوں کی فہرست کو ٹریوس سی آئی، بڈی اور ایپ ویور جیسے مشہور CI (مسلسل انٹیگریشن) سسٹم میں کیسے چیک کیا جائے۔
فائل لسٹ چیکنگ موڈ
ورژن PVS-Studio 7.04 for Linux اور macOS میں، سورس فائلوں کی فہرست کو چیک کرنے کا ایک موڈ نمودار ہوا ہے۔ یہ ان پروجیکٹس کے لیے کام کرتا ہے جن کا بلڈ سسٹم آپ کو فائل بنانے کی اجازت دیتا ہے۔
نیز، فائل لسٹ چیکنگ موڈ کو کمپائلر لانچز (pvs-studio-analyzer ٹریس) کے سٹریس ٹریس لاگ کے ساتھ استعمال کیا جا سکتا ہے۔ ایسا کرنے کے لیے، آپ کو پہلے پراجیکٹ کی مکمل تعمیر کو انجام دینے اور اسے ٹریک کرنے کی ضرورت ہوگی تاکہ تجزیہ کار ان تمام فائلوں کے کمپلیشن پیرامیٹرز کے بارے میں مکمل معلومات جمع کر سکے جو چیک کی جا رہی ہیں۔
تاہم، اس آپشن میں ایک اہم خرابی ہے - جب بھی آپ اسے چلاتے ہیں تو آپ کو یا تو پورے پروجیکٹ کا مکمل بلڈ ٹریس انجام دینے کی ضرورت ہوگی، جو بذات خود کسی کمٹمنٹ کی فوری جانچ پڑتال کے خیال سے متصادم ہے۔ یا، اگر آپ خود ٹریس کے نتیجے کو کیش کرتے ہیں، تو تجزیہ کار کے بعد کے رن نامکمل ہوسکتے ہیں اگر ٹریس کے بعد سورس فائلوں کا انحصار ڈھانچہ تبدیل ہوجائے (مثال کے طور پر، سورس فائلوں میں سے کسی ایک میں ایک نیا #include شامل کیا جاتا ہے)۔
لہذا، ہم کمٹ کی جانچ پڑتال یا درخواستوں کو کھینچنے کے لیے ٹریس لاگ کے ساتھ فائل لسٹ چیک موڈ استعمال کرنے کی سفارش نہیں کرتے ہیں۔ اگر آپ کمٹ کی جانچ پڑتال کرتے وقت ایک اضافی تعمیر کرسکتے ہیں تو، موڈ کو استعمال کرنے پر غور کریں۔
تجزیہ کے لیے سورس فائلوں کی فہرست ٹیکسٹ فائل میں محفوظ کی جاتی ہے اور پیرامیٹر کا استعمال کرتے ہوئے تجزیہ کار کو بھیجی جاتی ہے۔ -S:
pvs-studio-analyzer analyze ... -f build/compile_commands.json -S check-list.txt
یہ فائل فائلوں کے لیے متعلقہ یا مطلق راستے بتاتی ہے، اور ہر نئی فائل کو نئی لائن پر ہونا چاہیے۔ تجزیہ کے لیے نہ صرف فائل کے نام بتانا قابل قبول ہے، بلکہ مختلف متن بھی۔ تجزیہ کار دیکھے گا کہ یہ فائل نہیں ہے اور لائن کو نظر انداز کر دے گا۔ اگر فائلوں کو دستی طور پر بیان کیا جائے تو یہ تبصرہ کرنے کے لیے مفید ہو سکتا ہے۔ تاہم، اکثر فائلوں کی فہرست CI میں تجزیہ کے دوران تیار کی جائے گی، مثال کے طور پر، یہ کمٹ یا پل کی درخواست کی فائلیں ہو سکتی ہیں۔
اب، اس موڈ کا استعمال کرتے ہوئے، آپ نئے کوڈ کو مرکزی ترقیاتی برانچ میں داخل ہونے سے پہلے اسے تیزی سے چیک کر سکتے ہیں۔ اس بات کو یقینی بنانے کے لیے کہ سکیننگ سسٹم تجزیہ کار کی وارننگز کا جواب دیتا ہے، افادیت پلگ کنورٹر پرچم شامل کیا --انڈیکیٹ-انتباہات:
plog-converter ... --indicate-warnings ... -o /path/to/report.tasks ...
اس جھنڈے کے ساتھ، کنورٹر ایک غیر صفر کوڈ واپس کرے گا اگر تجزیہ کار رپورٹ میں انتباہات ہوں گے۔ ریٹرن کوڈ کا استعمال کرتے ہوئے، آپ پری کمٹ ہک، کمٹ، یا پل کی درخواست کو بلاک کر سکتے ہیں، اور تیار کردہ تجزیہ کار رپورٹ کو ای میل کے ذریعے ڈسپلے، شیئر یا بھیجا جا سکتا ہے۔
نوٹ. جب آپ سب سے پہلے فائلوں کی فہرست کا تجزیہ کرنا شروع کرتے ہیں، تو پورے پروجیکٹ کا تجزیہ کیا جائے گا، کیونکہ تجزیہ کار کو ہیڈر فائلوں پر پروجیکٹ سورس فائلوں کے انحصار کی فائل تیار کرنے کی ضرورت ہے۔ یہ C اور C++ فائلوں کا تجزیہ کرنے کی ایک خصوصیت ہے۔ مستقبل میں، انحصار فائل کو کیش کیا جا سکتا ہے اور اسے تجزیہ کار کے ذریعہ خود بخود اپ ڈیٹ کیا جائے گا۔ انکریمنٹل اینالیسس موڈ کا استعمال کرتے ہوئے فائل لسٹ چیکنگ موڈ کا استعمال کرتے وقت کمٹ چیک کرنے کا فائدہ یہ ہے کہ آپ کو صرف اس فائل کو کیش کرنے کی ضرورت ہے نہ کہ آبجیکٹ فائلوں کو۔
پل کی درخواست کے تجزیہ کے عمومی اصول
پورے پروجیکٹ کا تجزیہ کرنے میں کافی وقت لگتا ہے، اس لیے اس کے صرف ایک مخصوص حصے کی جانچ کرنا سمجھ میں آتا ہے۔ مسئلہ یہ ہے کہ آپ کو نئی فائلوں کو باقی پروجیکٹ فائلوں سے الگ کرنے کی ضرورت ہے۔
آئیے دو شاخوں والے کمٹ ٹری کی ایک مثال دیکھیں:
آئیے اس عزم کا تصور کریں۔ 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
یہ کمانڈ غلطیوں کی فہرست بنائے گی۔
صرف اب ہمیں نہ صرف غلطیوں کو ظاہر کرنے کی ضرورت ہے بلکہ مسائل کی موجودگی کے بارے میں اسمبلی اور جانچ کے لیے اپنی سروس کو مطلع کرنے کی بھی ضرورت ہے۔ اس مقصد کے لیے کنورٹر میں ایک جھنڈا شامل کیا گیا۔ -W (--انڈیکیٹ-انتباہات)۔ اگر کم از کم ایک تجزیہ کار انتباہ ہے تو، یوٹیلیٹی ریٹرن کوڈ پلگ کنورٹر 2 میں تبدیل ہو جائے گا، جس کے نتیجے میں CI سروس کو پل ریکوئسٹ فائلوں میں ممکنہ خامیوں کی موجودگی کے بارے میں مطلع کیا جائے گا۔
ٹریوس سی آئی
ترتیب ایک فائل کے طور پر بنائی گئی ہے۔ 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
اور 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_PULL_REQUEST پل ریکوئسٹ نمبر اسٹور کرتا ہے یا جھوٹیاگر یہ ایک باقاعدہ شاخ ہے؛
- $TRAVIS_REPO_SLUG پروجیکٹ کے ذخیرے کا نام محفوظ کرتا ہے۔
اس فنکشن کے لیے الگورتھم:
ٹریوس سی آئی واپسی کوڈز کا جواب دیتا ہے، لہذا انتباہات کی موجودگی سروس کو بتائے گی کہ کمٹ کو غلطیوں پر مشتمل نشان زد کرے۔
اب آئیے کوڈ کی اس لائن کو قریب سے دیکھیں:
git diff --name-only origin/HEAD > .pvs-pr.list
حقیقت یہ ہے کہ ٹریوس سی آئی پل کی درخواست کا تجزیہ کرتے ہوئے خود بخود شاخوں کو ضم کرتا ہے۔
اس لیے ہم تجزیہ کرتے ہیں۔ A4اور نہیں B3->A3. اس خصوصیت کی وجہ سے، ہمیں فرق کے ساتھ حساب کرنے کی ضرورت ہے۔ A3، جو برانچ کے بالکل اوپر سے ہے۔ اصل.
ایک اہم تفصیل باقی ہے - مرتب شدہ ترجمہ یونٹس (*.c، *.cc، *.cpp، وغیرہ) پر ہیڈر فائلوں کی انحصار کو کیش کرنا۔ تجزیہ کار ان انحصاروں کا حساب لگاتا ہے جب اسے پہلی بار فائلوں کی فہرست چیک کرنے کے موڈ میں لانچ کیا جاتا ہے اور پھر انہیں .PVS-Studio ڈائرکٹری میں محفوظ کرتا ہے۔ Travis CI آپ کو فولڈرز کیش کرنے کی اجازت دیتا ہے، لہذا ہم ڈائریکٹری ڈیٹا کو محفوظ کریں گے۔ .PVS-Studio/:
cache:
directories:
- .PVS-Studio/
اس کوڈ کو فائل میں شامل کرنے کی ضرورت ہے۔ travis.yml. یہ ڈائرکٹری تجزیہ کے بعد جمع کیے گئے مختلف ڈیٹا کو ذخیرہ کرتی ہے، جو فائل لسٹ کے تجزیہ یا انکریمنٹل تجزیہ کے بعد کے رنز کو نمایاں طور پر تیز کرے گی۔ اگر ایسا نہیں کیا جاتا ہے، تو تجزیہ کار اصل میں ہر بار تمام فائلوں کا تجزیہ کرے گا۔
دوست
ٹریوس سی آئی کی طرح،
سب سے پہلے، ہمیں اسمبلی لائن میں ایک نئی کارروائی شامل کرنے کی ضرورت ہے:
آئیے اس کمپائلر کی نشاندہی کریں جو پروجیکٹ کی تعمیر کے لیے استعمال کیا گیا تھا۔ ڈوکر کنٹینر کو دیکھیں جو اس کارروائی میں نصب ہے۔ مثال کے طور پر، 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
اب چلیں ٹیب پر جائیں (پہلا آئیکن) اور درج ذیل کوڈ کو متعلقہ ایڈیٹر فیلڈ میں شامل کریں:
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
تعین کرنے کے ل For 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 کے لیے لاگ ان اور پاس ورڈ کو محفوظ کرنا۔ تبدیلیاں محفوظ کرنے کے بعد، ہمیں واپس پائپ لائن پر لے جایا جائے گا۔ ہمیں متغیرات کو ترتیب دینے اور PVS-Studio کے لیے لاگ ان اور کلید شامل کرنے کے لیے آگے بڑھنے کی ضرورت ہے:
اس کے بعد، ایک نئی پل کی درخواست یا کمٹ کی ظاہری شکل جائزہ کو متحرک کرے گی۔ اگر کسی کمٹ میں غلطیاں ہوں تو بڈی پل کی درخواست کے صفحہ پر اس کی نشاندہی کرے گا۔
AppVeyor
AppVeyor کو سیٹ اپ کرنا Buddy کی طرح ہے، کیونکہ سب کچھ ویب انٹرفیس میں ہوتا ہے اور پروجیکٹ ریپوزٹری میں *.yml فائل کو شامل کرنے کی ضرورت نہیں ہے۔
آئیے پروجیکٹ کے جائزہ میں ترتیبات کے ٹیب پر جائیں:
آئیے اس صفحہ کو نیچے سکرول کریں اور پل کی درخواستوں کو جمع کرنے کے لیے کیشے کی بچت کو فعال کریں:
اب آئیے Environment ٹیب پر جائیں، جہاں ہم اسمبلی کے لیے تصویر اور ضروری ماحولیاتی متغیرات کی وضاحت کرتے ہیں:
اگر آپ نے پچھلے حصے پڑھے ہیں، تو آپ ان دو متغیرات سے بہت واقف ہیں۔ 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 میں تجزیہ کار ترتیب دینے کے دوران، مجھے تجزیہ کار کے انتہائی عجیب رویے کا سامنا کرنا پڑا۔ ایک طرف، سب کچھ صحیح طریقے سے کام کرتا ہے، لیکن تجزیہ شروع نہیں ہوا. میں نے یہ دیکھتے ہوئے کافی وقت صرف کیا کہ ہم /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 میں، آپ کو صرف سیٹنگز میں فولڈر کی وضاحت کرنے کی ضرورت ہے۔ لیکن کہیں آپ کو منفرد کلیدیں بنانے کی ضرورت ہے اور سسٹم کو قائل کرنے کی کوشش کریں کہ آپ کو کیش شدہ ٹکڑے کو اوور رائٹ کرنے کا موقع فراہم کرے۔ لہذا، اگر آپ مسلسل انٹیگریشن سروس پر پل کی درخواستوں کا تجزیہ ترتیب دینا چاہتے ہیں جس پر اوپر بات نہیں کی گئی ہے، تو پہلے اس بات کو یقینی بنائیں کہ آپ کو کیشنگ میں دشواری نہیں ہوگی۔
آپکی توجہ کا شکریہ. اگر کچھ کام نہیں کرتا ہے، تو بلا جھجھک ہمیں لکھیں۔
اگر آپ انگریزی بولنے والے سامعین کے ساتھ اس مضمون کا اشتراک کرنا چاہتے ہیں، تو براہ کرم ترجمہ کا لنک استعمال کریں: Maxim Zvyagintsev۔
ماخذ: www.habr.com