स्क्रिप्ट से Bazel को कॉल किया जा रहा है

स्क्रिप्ट से Bazel को कॉल करके, बिल्ड किया जा सकता है, टेस्ट चलाए जा सकते हैं या डिपेंडेंसी ग्राफ़ के बारे में क्वेरी की जा सकती है. Bazel को असरदार स्क्रिप्टिंग के लिए डिज़ाइन किया गया है. हालांकि, इस सेक्शन में कुछ ऐसी जानकारी दी गई है जिसे ध्यान में रखकर, अपनी स्क्रिप्ट को ज़्यादा मज़बूत बनाया जा सकता है.

आउटपुट बेस चुनना

--output_base विकल्प से यह कंट्रोल किया जाता है कि Bazel प्रोसेस को बिल्ड के आउटपुट कहां लिखने चाहिए. साथ ही, Bazel के अंदरूनी तौर पर इस्तेमाल की जाने वाली अलग-अलग वर्किंग फ़ाइलें कहां लिखनी चाहिए. इनमें से एक फ़ाइल, लॉक होती है. यह लॉक, एक से ज़्यादा Bazel प्रोसेस से आउटपुट बेस में एक साथ होने वाले बदलावों से बचाता है.

अपनी स्क्रिप्ट के लिए सही आउटपुट बेस डायरेक्ट्री चुनना, कई चीज़ों पर निर्भर करता है. अगर आपको बिल्ड के आउटपुट किसी खास जगह पर रखने हैं, तो इससे यह तय होगा कि आपको किस आउटपुट बेस का इस्तेमाल करना है. अगर आपको Bazel को "सिर्फ़ पढ़ने" के लिए कॉल करना है (जैसे, bazel query), तो लॉकिंग फ़ैक्टर ज़्यादा अहम होंगे. खास तौर पर, अगर आपको अपनी स्क्रिप्ट के कई इंस्टेंस एक साथ चलाने हैं, तो आपको हर इंस्टेंस के लिए अलग (या रैंडम) आउटपुट बेस देना होगा.

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

सर्वर मोड के बारे में नोट

डिफ़ॉल्ट रूप से, Bazel ऑप्टिमाइज़ेशन के तौर पर, लंबे समय तक चलने वाली सर्वर प्रोसेस का इस्तेमाल करता है. किसी स्क्रिप्ट में Bazel को चलाते समय, सर्वर का इस्तेमाल पूरा होने के बाद shutdown को कॉल करना न भूलें. इसके अलावा, --max_idle_secs=5 तय करें, ताकि आइडल सर्वर तुरंत बंद हो जाएं.

मुझे कौन सा एग्ज़िट कोड मिलेगा?

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

सभी कमांड के लिए सामान्य एग्ज़िट कोड:

• 0 - प्रोसेस पूरी हुई
• 2 - कमांड लाइन में गड़बड़ी, गलत या गैर-कानूनी फ़्लैग या कमांड कॉम्बिनेशन या गलत एनवायरमेंट वैरिएबल. आपको अपनी कमांड लाइन में बदलाव करना होगा.
• 8 - बिल्ड में रुकावट आई, लेकिन हमने इसे व्यवस्थित तरीके से बंद कर दिया.
• 9 - सर्वर लॉक है और --noblock_for_lock पास किया गया है.

• 32 - बाहरी एनवायरमेंट में गड़बड़ी. यह गड़बड़ी इस मशीन पर नहीं है.

• 33 - Bazel की मेमोरी खत्म हो गई और वह क्रैश हो गया. आपको अपनी कमांड लाइन में बदलाव करना होगा.

• 34 - Google के अंदरूनी इस्तेमाल के लिए रिज़र्व किया गया है.

• 35 - Google के अंदरूनी इस्तेमाल के लिए रिज़र्व किया गया है.

• 36 - स्थानीय एनवायरमेंट में गड़बड़ी. इसके स्थायी होने की आशंका है.

• 37 - हैंडल न की गई गड़बड़ी / Bazel में अंदरूनी गड़बड़ी.

• 38 - Google के अंदरूनी इस्तेमाल के लिए रिज़र्व किया गया है.

• 39 - Bazel के लिए ज़रूरी ब्लॉब, रिमोट कैश से हटा दिए गए हैं.

• 41-44 - Google के अंदरूनी इस्तेमाल के लिए रिज़र्व किया गया है.

• 45 - बिल्ड इवेंट सेवा में नतीजे पब्लिश करने में गड़बड़ी हुई.

• 47 - Google के अंदरूनी इस्तेमाल के लिए रिज़र्व किया गया है.

कमांड bazel build, bazel test के लिए, रिटर्न कोड:

• 1 - बिल्ड नहीं किया जा सका.
• 3 - बिल्ड हो गया है, लेकिन कुछ टेस्ट फ़ेल हो गए या उनका समय खत्म हो गया.
• 4 - बिल्ड हो गया है, लेकिन टेस्ट करने का अनुरोध किए जाने के बावजूद, कोई टेस्ट नहीं मिला.

bazel run के लिए:

• 1 - बिल्ड नहीं किया जा सका.
• अगर बिल्ड हो जाता है, लेकिन एक्ज़ीक्यूट की गई सबप्रोसेस, नॉन-ज़ीरो एग्ज़िट कोड दिखाती है, तो यह कमांड का एग्ज़िट कोड भी होगा.

bazel query के लिए:

• 3 - प्रोसेस पूरी हुई, लेकिन क्वेरी में इनपुट BUILD फ़ाइल सेट में एक या उससे ज़्यादा गड़बड़ियां मिलीं. इसलिए, ऑपरेशन के नतीजे 100% भरोसेमंद नहीं हैं. ऐसा होने की वजह, कमांड लाइन पर --keep_going विकल्प का इस्तेमाल करना हो सकता है.
• 7 - कमांड में गड़बड़ी हुई.

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

.bazelrc फ़ाइल पढ़ना

डिफ़ॉल्ट रूप से, Bazel, .bazelrc फ़ाइल को बेस वर्कस्पेस डायरेक्ट्री या उपयोगकर्ता की होम डायरेक्ट्री से पढ़ता है. यह तय करना आपकी स्क्रिप्ट पर निर्भर करता है कि आपको ऐसा करना है या नहीं. अगर आपकी स्क्रिप्ट को पूरी तरह से हर्मेटिक होना चाहिए (जैसे, रिलीज़ बिल्ड करते समय), तो आपको --bazelrc=/dev/null विकल्प का इस्तेमाल करके, .bazelrc फ़ाइल को पढ़ने की सुविधा बंद करनी चाहिए. अगर आपको उपयोगकर्ता की पसंदीदा सेटिंग का इस्तेमाल करके बिल्ड करना है, तो डिफ़ॉल्ट व्यवहार बेहतर है.

कमांड लॉग

Bazel का आउटपुट, कमांड लॉग फ़ाइल में भी उपलब्ध होता है. इसे इस कमांड की मदद से ढूंढा जा सकता है:

bazel info command_log

कमांड लॉग फ़ाइल में, सबसे हाल के Bazel कमांड के इंटरलीव्ड stdout और stderr स्ट्रीम शामिल होते हैं. ध्यान दें कि bazel info चलाने पर, इस फ़ाइल का कॉन्टेंट मिट जाएगा. इसकी वजह यह है कि यह सबसे हाल का Bazel कमांड बन जाता है. हालांकि, कमांड लॉग फ़ाइल की जगह तब तक नहीं बदलेगी, जब तक कि --output_base या --output_user_root विकल्पों की सेटिंग में बदलाव नहीं किया जाता.

आउटपुट पार्स करना

Bazel के आउटपुट को कई मकसद के लिए आसानी से पार्स किया जा सकता है. आपके स्क्रिप्ट के लिए दो विकल्प काम के हो सकते हैं. पहला, --noshow_progress. इससे प्रोग्रेस मैसेज नहीं दिखते. दूसरा, --show_result n. इससे यह कंट्रोल किया जाता है कि "बिल्ड अप-टू-डेट" मैसेज प्रिंट किए जाएं या नहीं. इन मैसेज को पार्स करके यह पता लगाया जा सकता है कि किन टारगेट को सफलतापूर्वक बिल्ड किया गया है. साथ ही, इनसे बनाई गई आउटपुट फ़ाइलों की जगह भी पता लगाई जा सकती है. अगर आपको इन मैसेज पर भरोसा है, तो n की बहुत बड़ी वैल्यू तय करें.

प्रोफ़ाइलिंग करके परफ़ॉर्मेंस से जुड़ी समस्याओं को हल करना

परफ़ॉर्मेंस प्रोफ़ाइलिंग सेक्शन देखें.