स्क्रिप्ट से Bazel को कॉल करके, बिल्ड किया जा सकता है, टेस्ट चलाए जा सकते हैं या डिपेंडेंसी ग्राफ़ के बारे में क्वेरी की जा सकती है. Bazel को असरदार स्क्रिप्टिंग की सुविधा देने के लिए डिज़ाइन किया गया है. हालांकि, इस सेक्शन में कुछ जानकारी दी गई है, जिसे ध्यान में रखकर अपनी स्क्रिप्ट को ज़्यादा बेहतर बनाया जा सकता है.
आउटपुट का आधार चुनना
--output_base
विकल्प से यह कंट्रोल किया जाता है कि Bazel प्रोसेस को किसी बिल्ड के आउटपुट कहां लिखने चाहिए. साथ ही, यह भी कंट्रोल किया जाता है कि Bazel में अंदरूनी तौर पर इस्तेमाल की जाने वाली अलग-अलग फ़ाइलों को कहां लिखना चाहिए. इनमें से एक फ़ाइल एक लॉक है, जो एक से ज़्यादा Bazel प्रोसेस के आउटपुट बेस में एक साथ बदलाव होने से बचाता है.
अपनी स्क्रिप्ट के लिए सही आउटपुट बेस डायरेक्ट्री चुनना, कई बातों पर निर्भर करता है. अगर आपको बिल्ड आउटपुट को किसी खास जगह पर डालना है, तो इससे आपको आउटपुट बेस का पता चलेगा. अगर आपने Bazel को "रीड ओनली" कॉल किया है, जैसे कि bazel query
, तो लॉक करने के फ़ैक्टर ज़्यादा अहम होंगे. खास तौर पर, अगर आपको एक साथ स्क्रिप्ट के कई इंस्टेंस चलाने हैं, तो आपको हर एक को एक अलग (या रैंडम) आउटपुट बेस देना होगा.
अगर आउटपुट की डिफ़ॉल्ट बेस वैल्यू का इस्तेमाल किया जाता है, तो आपको उसी लॉक के लिए मुकाबला करना होगा जिसका इस्तेमाल उपयोगकर्ता के इंटरैक्टिव Bazel निर्देशों में किया जाता है. अगर उपयोगकर्ता, बिल्ड जैसे लंबे समय तक चलने वाले निर्देश देता है, तो आपकी स्क्रिप्ट को उन निर्देशों के पूरा होने का इंतज़ार करना होगा. इसके बाद ही, वह आगे की कार्रवाई कर पाएगी.
सर्वर मोड के बारे में जानकारी
डिफ़ॉल्ट रूप से, Bazel ऑप्टिमाइज़ेशन के तौर पर, लंबे समय तक चलने वाली सर्वर प्रोसेस का इस्तेमाल करता है. किसी स्क्रिप्ट में Bazel को चलाते समय, सर्वर का इस्तेमाल करने के बाद shutdown
को कॉल करना न भूलें. इसके अलावा, --max_idle_secs=5
का इस्तेमाल करके, यह भी तय किया जा सकता है कि कोई भी सर्वर बिना काम के न रहे.
मुझे कौनसा एक्सिट कोड मिलेगा?
Bazel, सोर्स कोड की वजह से होने वाली गड़बड़ियों और बाहरी गड़बड़ियों के बीच अंतर करने की कोशिश करता है. बाहरी गड़बड़ियों की वजह से, Bazel ठीक से काम नहीं कर पाता. Bazel को चलाने पर, ये एग्ज़िट कोड दिख सकते हैं:
सभी निर्देशों के लिए सामान्य Exit Code:
0
- सफल2
- कमांड लाइन से जुड़ी समस्या, खराब या गैर-कानूनी फ़्लैग या कमांड कॉम्बिनेशन या खराब एनवायरमेंट वैरिएबल. आपकी कमांड लाइन में बदलाव करना होगा.8
- बिल्ड में रुकावट आई, लेकिन हमने इसे व्यवस्थित तरीके से बंद कर दिया.9
- सर्वर लॉक हो गया है और--noblock_for_lock
पास हो गया है.32
- बाहरी एनवायरमेंट से जुड़ी गड़बड़ी, इस मशीन पर नहीं है.33
- Bazel की मेमोरी खत्म हो गई और वह क्रैश हो गया. आपको अपनी कमांड लाइन में बदलाव करना होगा.34
- Google के अंदर इस्तेमाल के लिए रिज़र्व किया गया.35
- Google के अंदर इस्तेमाल के लिए रिज़र्व किया गया.36
- स्थानीय पर्यावरण से जुड़ी समस्या, जो शायद हमेशा के लिए हो.37
- Unhandled Exception / Internal Bazel Error.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
को किसी ऐसी वैल्यू से बदला जा सकता है जो शून्य से अलग हो और जिसका कोई खास मतलब हो.
हालांकि, सभी गैर-शून्य एक्ज़िट वैल्यू से हमेशा एक गड़बड़ी होगी.
.baezrc फ़ाइल को पढ़ा जा रहा है
डिफ़ॉल्ट रूप से, 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 की बहुत बड़ी वैल्यू डालना न भूलें.
प्रोफ़ाइलिंग की मदद से परफ़ॉर्मेंस से जुड़ी समस्या हल करना
परफ़ॉर्मेंस प्रोफ़ाइल सेक्शन देखें.