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

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

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

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

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

ऐसे नियम ढूंढना जो पूरी तरह से लागू नहीं होते

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