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

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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