Workspace के नियमों में नॉन-हार्मेटिक व्यवहार ढूंढना

यहां, होस्ट मशीन वह मशीन है जिस पर Bazel चलता है.

रिमोट एक्ज़ीक्यूशन का इस्तेमाल करने पर, असल में बिल्ड और/या टेस्ट के चरण, होस्ट मशीन पर नहीं होते. इसके बजाय, इन्हें रिमोट एक्ज़ीक्यूशन सिस्टम पर भेज दिया जाता है. हालांकि, वर्कस्पेस के नियमों को लागू करने के लिए ज़रूरी चरण, होस्ट मशीन पर पूरे किए जाते हैं. अगर आपके वर्कस्पेस के नियमों में, एक्ज़ीक्यूशन के दौरान इस्तेमाल करने के लिए होस्ट मशीन के ऐक्सेस की जानकारी शामिल है, तो हो सकता है कि एनवायरमेंट के बीच काम न करने की वजह से आपका बिल्ड काम न करे.

रिमोट एक्ज़ीक्यूशन के लिए Bazel नियमों को अडैप्ट करने के लिए, आपको ऐसे वर्कस्पेस के नियमों को ढूंढना होगा और उन्हें ठीक करना होगा. इस पेज पर, वर्कस्पेस के लॉग का इस्तेमाल करके, वर्कस्पेस की उन नियमों का पता लगाने का तरीका बताया गया है जिनमें समस्या हो सकती है.

नॉन-हर्मेटिक नियमों का पता लगाना

वर्कस्पेस के नियमों की मदद से डेवलपर, बाहरी वर्कस्पेस में डिपेंडेंसी जोड़ सकता है. हालांकि, ये नियम इतने बेहतर होते हैं कि प्रोसेस के दौरान किसी भी तरह की प्रोसेसिंग की जा सकती है. इससे जुड़ी सभी कार्रवाइयां स्थानीय तौर पर होती हैं. इसलिए, यह गैर-हर्मेटिक होने का संभावित सोर्स हो सकता है. आम तौर पर, नॉन-हर्मेटिक व्यवहार को repository_ctx के ज़रिए लागू किया जाता है. इससे होस्ट मशीन के साथ इंटरैक्ट किया जा सकता है.

Bazel 0.18 से, कुछ ऐसी कार्रवाइयों का लॉग पाया जा सकता है जो हर्मेटिक नहीं हैं. इसके लिए, आपको अपनी Bazel कमांड में --experimental_workspace_rules_log_file=[PATH] फ़्लैग जोड़ना होगा. यहां [PATH] एक फ़ाइल का नाम है, जिसके तहत लॉग बनाया जाएगा.

इन बातों का ध्यान रखें:

• यह लॉग, इवेंट के एक्ज़ीक्यूट होने के साथ-साथ उन्हें कैप्चर करता है. अगर कुछ चरणों को कैश मेमोरी में सेव किया जाता है, तो वे लॉग में नहीं दिखेंगे. इसलिए, पूरा नतीजा पाने के लिए, bazel clean --expunge को पहले से चलाना न भूलें.

• कभी-कभी फ़ंक्शन को फिर से लागू किया जा सकता है. ऐसे में, उनसे जुड़े इवेंट लॉग में कई बार दिखेंगे.

• Workspace के नियम, फ़िलहाल सिर्फ़ Starlark इवेंट लॉग करते हैं.

वर्कस्पेस शुरू होने के दौरान क्या-क्या कार्रवाइयां की गईं, यह देखने के लिए:

1. bazel clean --expunge रन करो. इस कमांड से, आपकी लोकल कैश मेमोरी और कैश मेमोरी में सेव की गई सभी रिपॉज़िटरी खाली हो जाएंगी. इससे यह पक्का किया जा सकेगा कि सभी इनिशियलाइज़ेशन फिर से चलाए जाएं.

2. अपनी Bazel कमांड में --experimental_workspace_rules_log_file=/tmp/workspacelog जोड़ें और बिल्ड चलाएं.

   इससे एक बाइनरी प्रोटो फ़ाइल जनरेट होती है. इसमें WorkspaceEvent टाइप के मैसेज की सूची होती है

3. Bazel के सोर्स कोड को डाउनलोड करें. इसके बाद, यहां दिए गए निर्देश का इस्तेमाल करके, Bazel फ़ोल्डर पर जाएं. workspacelog parser की मदद से, Workspace के लॉग को पार्स करने के लिए, आपको सोर्स कोड की ज़रूरत होगी.

   git clone https://github.com/bazelbuild/bazel.git
   cd bazel

4. Bazel के सोर्स कोड रेपो में, पूरे वर्कस्पेस के लॉग को टेक्स्ट में बदलें.

   bazel build src/tools/workspacelog:parser
   bazel-bin/src/tools/workspacelog/parser --log_path=/tmp/workspacelog > /tmp/workspacelog.txt

5. आउटपुट में ज़्यादा जानकारी हो सकती है. इसमें Bazel के बिल्ट-इन नियमों का आउटपुट भी शामिल हो सकता है.

   आउटपुट से कुछ नियमों को बाहर रखने के लिए, --exclude_rule विकल्प का इस्तेमाल करें. उदाहरण के लिए:

   bazel build src/tools/workspacelog:parser
   bazel-bin/src/tools/workspacelog/parser --log_path=/tmp/workspacelog \
       --exclude_rule "//external:local_config_cc" \
       --exclude_rule "//external:dep" > /tmp/workspacelog.txt

6. /tmp/workspacelog.txt खोलें और देखें कि कोई असुरक्षित कार्रवाई तो नहीं की गई है.

इस लॉग में WorkspaceEvent मैसेज शामिल होते हैं. इनमें repository_ctx पर की गई कुछ ऐसी कार्रवाइयों के बारे में बताया जाता है जो संभावित रूप से हर्मेटिक नहीं हैं.

जिन कार्रवाइयों को संभावित रूप से नॉन-हर्मेटिक के तौर पर हाइलाइट किया गया है वे ये हैं:

• execute: होस्ट एनवायरमेंट पर कोई भी कमांड चलाता है. देखें कि क्या ये होस्ट एनवायरमेंट पर कोई निर्भरता लागू कर सकते हैं.

• download, download_and_extract: यह पक्का करने के लिए कि बिल्ड पूरी तरह से अलग-थलग हों, पक्का करें कि sha256 की जानकारी दी गई हो

• file, template: यह अपने-आप में नॉन-हर्मेटिक नहीं है. हालांकि, यह रिपॉज़िटरी में होस्ट एनवायरमेंट पर निर्भरता बढ़ाने का एक तरीका हो सकता है. पक्का करें कि आपको पता हो कि इनपुट कहां से मिल रहा है और यह होस्ट एनवायरमेंट पर निर्भर नहीं करता है.

• os: यह अपने-आप में नॉन-हर्मेटिक नहीं है, लेकिन होस्ट एनवायरमेंट पर डिपेंडेंसी पाने का एक आसान तरीका है. आम तौर पर, हर्मेटिक बिल्ड इसे कॉल नहीं करेगा. यह आकलन करते समय कि आपका इस्तेमाल हर्मेटिक है या नहीं, ध्यान रखें कि यह होस्ट पर चल रहा है, न कि वर्कर पर. आम तौर पर, रिमोट बिल्ड के लिए होस्ट से एनवायरमेंट की खास जानकारी पाना सही नहीं होता.

• symlink: आम तौर पर, यह सुरक्षित होता है. हालांकि, लाल रंग के फ़्लैग पर ध्यान दें. रिपॉज़िटरी के बाहर या ऐब्सलूट पाथ पर मौजूद किसी भी सिमलंक की वजह से, रिमोट वर्कर को समस्याएं आ सकती हैं. अगर सिमलंक को होस्ट मशीन की प्रॉपर्टी के आधार पर बनाया जाता है, तो शायद यह भी समस्या पैदा कर सकता है.

• which: होस्ट पर इंस्टॉल किए गए प्रोग्राम की जांच करना आम तौर पर मुश्किल होता है, क्योंकि वर्कर के पास अलग-अलग कॉन्फ़िगरेशन हो सकते हैं.