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

समस्या की शिकायत करें सोर्स देखें Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

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

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

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

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

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

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

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

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

ध्यान दें: जब तक हैश तय नहीं किया जाता, तब तक इन नियमों से हर्मेटिसिटी से जुड़ी समस्याएं नहीं होती हैं.

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

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

इससे एक बाइनरी प्रोटो फ़ाइल जनरेट होती है. इसमें WorkspaceEvent टाइप के मैसेज की सूची होती है
Bazel के सोर्स कोड को डाउनलोड करें. इसके बाद, यहां दिए गए निर्देश का इस्तेमाल करके, Bazel फ़ोल्डर पर जाएं. workspacelog parser की मदद से, Workspace के लॉग को पार्स करने के लिए, आपको सोर्स कोड की ज़रूरत होगी.
```
git clone https://github.com/bazelbuild/bazel.git
cd bazel
```
Bazel के सोर्स कोड रेपो में, पूरे वर्कस्पेस के लॉग को टेक्स्ट में बदलें.
```
bazel build src/tools/workspacelog:parser
bazel-bin/src/tools/workspacelog/parser --log_path=/tmp/workspacelog > /tmp/workspacelog.txt
```
आउटपुट में ज़्यादा जानकारी हो सकती है. इसमें 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
```
/tmp/workspacelog.txt खोलें और देखें कि कोई असुरक्षित कार्रवाई तो नहीं की गई है.

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

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

execute: यह होस्ट एनवायरमेंट पर आर्बिट्ररी कमांड को एक्ज़ीक्यूट करता है. देखें कि क्या ये होस्ट एनवायरमेंट पर कोई निर्भरता लागू कर सकते हैं.
download, download_and_extract: यह पक्का करने के लिए कि बिल्ड पूरी तरह से अलग-थलग हों, पक्का करें कि sha256 की जानकारी दी गई हो
file, template: यह अपने-आप में नॉन-हर्मेटिक नहीं है, लेकिन यह रिपॉज़िटरी में होस्ट एनवायरमेंट पर डिपेंडेंसी लागू करने का तरीका हो सकता है. पक्का करें कि आपको पता हो कि इनपुट कहां से मिल रहा है और यह होस्ट एनवायरमेंट पर निर्भर न हो.
os: यह अपने-आप में नॉन-हर्मेटिक नहीं है, लेकिन होस्ट एनवायरमेंट पर डिपेंडेंसी पाने का एक आसान तरीका है. आम तौर पर, हर्मेटिक बिल्ड इसे कॉल नहीं करेगा. यह आकलन करते समय कि आपका इस्तेमाल हर्मेटिक है या नहीं, ध्यान रखें कि यह होस्ट पर चल रहा है, न कि वर्कर पर. आम तौर पर, रिमोट बिल्ड के लिए होस्ट से एनवायरमेंट की खास जानकारी पाना सही नहीं होता.
symlink: आम तौर पर, यह सुरक्षित होता है. हालांकि, आपको कुछ गड़बड़ियां दिख सकती हैं. रिपॉज़िटरी के बाहर या ऐब्सलूट पाथ पर मौजूद किसी भी सिमलंक से, रिमोट वर्कर को समस्याएं हो सकती हैं. अगर सिमलंक को होस्ट मशीन की प्रॉपर्टी के आधार पर बनाया जाता है, तो इससे भी समस्या हो सकती है.
which: होस्ट पर इंस्टॉल किए गए प्रोग्राम की जांच करना आम तौर पर मुश्किल होता है, क्योंकि वर्कर के पास अलग-अलग कॉन्फ़िगरेशन हो सकते हैं.