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

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

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

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

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

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

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

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

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

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

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

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

• 32 - External Environment Failure not on this machine.

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

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

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

• 36 - स्थानीय पर्यावरणीय समस्या, जिसके ठीक होने की संभावना नहीं है.

• 37 - Unhandled Exception / Internal Bazel Error.

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

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

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

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

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

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

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

bazel run के लिए:

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

bazel query के लिए:

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

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

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