बिल्ड करने, टेस्ट चलाने या डिपेंडेंसी ग्राफ़ पर क्वेरी करने के लिए, स्क्रिप्ट से Baज़ल को कॉल किया जा सकता है. Basel को असरदार स्क्रिप्टिंग के लिए डिज़ाइन किया गया है. हालांकि, इस सेक्शन में कुछ जानकारी दी गई है, ताकि आपकी स्क्रिप्ट को बेहतर बनाया जा सके.
आउटपुट का आधार चुनना
--output_base
विकल्प से यह कंट्रोल किया जाता है कि Basel प्रोसेस को किसी बिल्ड के आउटपुट का आउटपुट कहां लिखना चाहिए. साथ ही, इसमें उन अलग-अलग फ़ाइलों को भी कंट्रोल किया जा सकता है जिनका इस्तेमाल Basel ने किया है. इनमें से एक लॉक, आउटपुट बेस के एक साथ होने वाले म्यूटेशन से, कई Basel प्रोसेस के ज़रिए आउटपुट बेस के म्यूटेशन से बचाता है.
अपनी स्क्रिप्ट के लिए सही आउटपुट बेस डायरेक्ट्री चुनना, कई बातों पर निर्भर करता है. अगर आपको बिल्ड आउटपुट को किसी खास जगह पर डालना है, तो इससे आपको आउटपुट बेस का पता चलेगा. अगर आप बैजेल को "रीड ओनली" कॉल कर रहे हैं (जैसे कि bazel query
), तो लॉक करने के कारक अधिक महत्वपूर्ण होंगे. खास तौर पर, अगर आपको अपनी स्क्रिप्ट के कई इंस्टेंस एक साथ चलाने हैं, तो आपको ध्यान रखना चाहिए कि हर Blaze सर्वर प्रोसेस, एक बार में ज़्यादा से ज़्यादा एक कॉल को हैंडल कर सकती है.
आपकी स्थिति के हिसाब से, हो सकता है कि आपकी स्क्रिप्ट के हर इंस्टेंस को अपनी बारी का इंतज़ार करना पड़े. इसके अलावा, --output_base
का इस्तेमाल करके एक से ज़्यादा Blaze सर्वर चलाए जा सकते हैं और उनका इस्तेमाल किया जा सकता है.
अगर डिफ़ॉल्ट आउटपुट बेस वैल्यू का इस्तेमाल किया जाता है, तो आपको उसी लॉक के लिए मुकाबला करना होगा जिसका इस्तेमाल उपयोगकर्ता के इंटरैक्टिव Baze कमांड में किया जा रहा है. अगर उपयोगकर्ता, बिल्ड जैसे लंबे समय तक चलने वाले निर्देश देता है, तो आपकी स्क्रिप्ट को उन निर्देशों के पूरा होने का इंतज़ार करना होगा. इसके बाद ही, वह आगे की कार्रवाई कर पाएगी.
सर्वर मोड के बारे में जानकारी
डिफ़ॉल्ट रूप से, Bazel ऑप्टिमाइज़ेशन के तौर पर, लंबे समय तक चलने वाली सर्वर प्रोसेस का इस्तेमाल करता है. किसी स्क्रिप्ट में Bazel को चलाते समय, सर्वर का इस्तेमाल करने के बाद shutdown
को कॉल करना न भूलें. इसके अलावा, --max_idle_secs=5
का इस्तेमाल करके, यह भी तय किया जा सकता है कि कोई भी सर्वर बिना काम के न रहे.
मुझे कौनसा एक्सिट कोड मिलेगा?
Basel, बाहरी गड़बड़ियों को ध्यान में रखते हुए सोर्स कोड की वजह से हो रही गड़बड़ियों के बीच अंतर करने की कोशिश करती है. इससे Baज़ल, सही तरीके से एक्ज़ीक्यूट नहीं हो पाता है. Bazel को चलाने पर, ये एग्ज़िट कोड दिख सकते हैं:
सभी कमांड के लिए इस्तेमाल होने वाले एग्ज़िट कोड:
0
- सफल2
- कमांड लाइन से जुड़ी समस्या, खराब या गैर-कानूनी फ़्लैग या कमांड कॉम्बिनेशन या खराब एनवायरमेंट वैरिएबल. आपकी कमांड लाइन में बदलाव करना होगा.8
- बिल्ड में रुकावट आई, लेकिन हमने इसे व्यवस्थित तरीके से बंद कर दिया.9
- सर्वर लॉक हो गया है और--noblock_for_lock
पास हो गया है.32
- बाहरी एनवायरमेंट से जुड़ी गड़बड़ी, इस मशीन पर नहीं है.33
- Basel की मेमोरी खत्म हो गई है और वह क्रैश हो गया. आपको अपनी कमांड लाइन में बदलाव करना होगा.34
- Google के अंदर इस्तेमाल के लिए रिज़र्व किया गया.35
- Google के अंदर इस्तेमाल के लिए रिज़र्व किया गया.36
- स्थानीय पर्यावरण से जुड़ी समस्या, जो शायद हमेशा के लिए हो.37
- Unhandled Exception / Internal Bazel Error.38
- Build Event Service में नतीजे पब्लिश करते समय, कुछ समय के लिए गड़बड़ी हुई.39
- Bazel के लिए ज़रूरी ब्लॉब, रिमोट कैश मेमोरी से हटा दिए जाते हैं.41-44
- Google के अंदर इस्तेमाल के लिए रिज़र्व किया गया.45
- Build Event Service में नतीजे पब्लिश करने में लगातार गड़बड़ी हो रही है.47
- Google के अंदर इस्तेमाल के लिए रिज़र्व किया गया.49
- Google के अंदर इस्तेमाल के लिए रिज़र्व किया गया.
bazel build
, bazel test
निर्देशों के लिए लौटाने के कोड:
1
- बिल्ड नहीं किया जा सका.3
- ठीक है, लेकिन कुछ टेस्ट पूरे नहीं हो सके या समय खत्म हो गया.4
- बिल्ड पूरा हो गया, लेकिन टेस्ट करने का अनुरोध करने के बावजूद कोई टेस्ट नहीं मिला.
bazel run
के लिए:
1
- बिल्ड नहीं हो सका.- अगर बिल्ड पूरा हो जाता है, लेकिन चलाई गई सबप्रोसेस से शून्य से ज़्यादा का एक्ज़िट कोड मिलता है, तो यह कमांड का एक्ज़िट कोड भी होगा.
bazel query
के लिए:
3
- कुछ हद तक काम हो गया, लेकिन क्वेरी को इनपुट BUILD फ़ाइल सेट में एक या उससे ज़्यादा गड़बड़ियां मिलीं. इसलिए, ऑपरेशन के नतीजे 100% भरोसेमंद नहीं हैं. ऐसा कमांड लाइन पर--keep_going
विकल्प की वजह से हो सकता है.7
- निर्देश पूरा नहीं हो सका.
आने वाले समय में, Bazel के वर्शन में और भी एग्ज़िट कोड जोड़े जा सकते हैं. साथ ही, गड़बड़ी के सामान्य एग्ज़िट कोड 1
को किसी ऐसी वैल्यू से बदला जा सकता है जो शून्य से अलग हो और जिसका कोई खास मतलब हो.
हालांकि, शून्य से ज़्यादा की सभी वैल्यू गड़बड़ी के तौर पर दिखेंगी.
.baezrc फ़ाइल को पढ़ा जा रहा है
डिफ़ॉल्ट रूप से, Basel, बुनियादी Workspace डायरेक्ट्री या उपयोगकर्ता की होम डायरेक्ट्री से
.bazelrc
फ़ाइल को पढ़ता है. आपकी स्क्रिप्ट के लिए यह तय करना ज़रूरी है या नहीं, यह तय करना होता है कि आपकी स्क्रिप्ट
पूरी तरह से हेर्मेटिक होनी चाहिए (जैसे कि रिलीज़ बिल्ड करते समय), तो आपको --bazelrc=/dev/null
विकल्प का इस्तेमाल करके, .bazzrc फ़ाइल को पढ़ने की सुविधा बंद कर देनी चाहिए. अगर आपको उपयोगकर्ता की पसंदीदा सेटिंग का इस्तेमाल करके कोई बिल्ड करना है, तो डिफ़ॉल्ट तरीके से काम करना बेहतर है.
कमांड लॉग
Basel आउटपुट एक कमांड लॉग फ़ाइल में भी उपलब्ध होता है, जिसे आपको इस कमांड की मदद से मिल सकता है:
bazel info command_log
कमांड लॉग फ़ाइल में, सबसे हाल ही के Bazel कमांड की इंटरलीव की गई stdout और stderr स्ट्रीम शामिल होती हैं. ध्यान दें कि bazel info
को चलाने पर, इस फ़ाइल का कॉन्टेंट बदल जाएगा, क्योंकि यह Bazel का सबसे नया निर्देश बन जाता है.
हालांकि, --output_base
या --output_user_root
विकल्पों की सेटिंग बदलने तक, कमांड लॉग फ़ाइल की जगह नहीं बदलेगी.
आउटपुट को पार्स करना
कई कामों के लिए, Bazel के आउटपुट को पार्स करना बहुत आसान है. आपकी स्क्रिप्ट के लिए, ये दो विकल्प मददगार हो सकते हैं: --noshow_progress
, जो प्रोग्रेस मैसेज को दबा देता है और --show_result n
, जो यह कंट्रोल करता है कि "अप-टू-डेट बिल्ड" मैसेज प्रिंट किए जाएं या नहीं. इन मैसेज को पार्स करके यह पता लगाया जा सकता है कि कौनसे टारगेट सही तरीके से बनाए गए और उन्होंने जो आउटपुट फ़ाइलें बनाई उनकी जगह क्या है. अगर आपको इन मैसेज पर भरोसा है, तो n की बहुत बड़ी वैल्यू डालना न भूलें.
प्रोफ़ाइलिंग की मदद से परफ़ॉर्मेंस से जुड़ी समस्या हल करना
परफ़ॉर्मेंस प्रोफ़ाइल सेक्शन देखें.