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

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

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

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

ऑफ़िस से दूर रहकर काम करने की सुविधा के लिए, Baज़र के नियमों को अपनाने के हिस्से के तौर पर, आपको Workspace के ऐसे नियमों को ढूंढकर उन्हें ठीक करना होगा. इस पेज पर, Workspace लॉग का इस्तेमाल करके, संभावित समस्या वाले 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. --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. आउटपुट बहुत ज़्यादा शब्दों वाला हो सकता है. इसमें, 'बेज़ल' में बने नियमों का आउटपुट शामिल हो सकता है.

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