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

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

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

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

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

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

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

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

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

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

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

वर्कस्पेस के शुरू होने के दौरान, क्या एक्ज़ीक्यूट किया गया, यह जानने के लिए:

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

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

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

3. Bazel का सोर्स कोड डाउनलोड करें और नीचे दी गई कमांड का इस्तेमाल करके, Bazel फ़ोल्डर पर जाएं. workspacelog पार्सर की मदद से, वर्कस्पेस के लॉग को पार्स करने के लिए, आपको सोर्स कोड की ज़रूरत होगी .

   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: होस्ट पर इंस्टॉल किए गए प्रोग्राम की जांच करना आम तौर पर समस्या पैदा करता है, क्योंकि वर्कर के कॉन्फ़िगरेशन अलग-अलग हो सकते हैं.