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

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

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