स्क्रिप्ट से 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 के अंदरूनी इस्तेमाल के लिए रिज़र्व किया गया.

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

• 45 - Build Event Service में नतीजे पब्लिश करने में गड़बड़ी हुई.

• 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 की बहुत बड़ी वैल्यू तय करें.

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

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