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

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

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

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