Bazel के कमांड लाइन फ़्लैग की बड़ी सूची में नेविगेट करना मुश्किल हो सकता है. इस पेज पर, उन सबसे ज़रूरी फ़्लैग के बारे में बताया गया है जिनके बारे में आपको जानना होगा.
काम के सामान्य विकल्प
यहां दिए गए फ़्लैग, कमांड-लाइन पर साफ़ तौर पर सेट किए जाने हैं.
| झंडा | ब्यौरा |
|---|---|
|
.bazelrc फ़ाइल में, फ़्लैग को कॉन्फ़िगरेशन में व्यवस्थित किया जा सकता है. जैसे, डीबग करने या रिलीज़ बिल्ड के लिए. --config=<group> का इस्तेमाल करके, अन्य कॉन्फ़िगरेशन ग्रुप चुने जा सकते हैं.
|
|
Bazel को बिल्ड और टेस्ट को पूरा करने की कोशिश करनी चाहिए. डिफ़ॉल्ट रूप से, Bazel तुरंत गड़बड़ी का पता लगाता है. |
|
रिमोट से प्रोग्राम चलाने या कैश मेमोरी का इस्तेमाल करने पर (डिस्क और रिमोट, दोनों), Bazel को यह सिग्नल दिया जा सकता है कि आपको सभी (इंटरमीडिएट) बिल्ड आर्टफ़ैक्ट डाउनलोड करने हैं. इसके लिए, यह तरीका अपनाएं:
--remote_download_outputs=all |
|
बाइनरी में बिल्ड की जानकारी (उपयोगकर्ता, टाइमस्टैंप) जोड़ता है. |
बिल्ड और टेस्ट से जुड़ी समस्याओं का पता लगाना
यहां दिए गए फ़्लैग से, आपको Bazel के बिल्ड या टेस्ट से जुड़ी गड़बड़ियों को बेहतर तरीके से समझने में मदद मिल सकती है.
| झंडा | ब्यौरा |
|---|---|
|
इससे पता चलता है कि उपयोगकर्ता, मशीन या प्रोजेक्ट की ओर से तय की गई .bazelrc फ़ाइलों की मदद से, कौनसे फ़्लैग अपने-आप सेट होते हैं. |
|
डिफ़ॉल्ट रूप से, Bazel लॉग स्पैम को रोकने की कोशिश करता है. साथ ही, कमांड लाइन पर अनुरोध किए गए पैकेज और सब-पैकेज के लिए, सिर्फ़ कंपाइलर की चेतावनियां और Starlark डीबग आउटपुट को प्रिंट करता है. सभी फ़िल्टर बंद करने के लिए, --auto_output_filter=none को सेट करें.
|
|
सैंडबॉक्सिंग से जुड़ी गड़बड़ियों के बारे में ज़्यादा जानकारी मिलती है. Bazel डिफ़ॉल्ट रूप से बाइनरी को सैंडबॉक्स क्यों करता है और सैंडबॉक्स में क्या जाता है, इस बारे में जानने के लिए, हमारा सैंडबॉक्सिंग दस्तावेज़ देखें. |
|
इसमें, हर उस कमांड की पूरी सूची दिखती है जिसे Bazel किसी बिल्ड के दौरान चलाता है. इससे कोई फ़र्क़ नहीं पड़ता कि बिल्ड पूरा होता है या नहीं |
स्टार्टअप
| झंडा | ब्यौरा |
|---|---|
|
.bazelrc फ़ाइलों में, Bazel के डिफ़ॉल्ट विकल्प तय किए जा सकते हैं. अगर एक से ज़्यादा .bazelrc फ़ाइलें मौजूद हैं, तो --bazelrc=<path to
the .bazelrc file> जोड़कर यह चुना जा सकता है कि किस .bazelrc फ़ाइल का इस्तेमाल किया जाए.
|
|
Bazel सर्वर के इस्तेमाल की जाने वाली रैम की सीमा तय करता है.
उदाहरण के लिए, यह विकल्प Bazel के ढेर के साइज़ को 3 जीबी तक सीमित करता है:
--host_jvm_args=-Xmx3g |
|
Bazel के आउटपुट ट्री को कंट्रोल करता है. Bazel, सोर्स ट्री में ही लॉग के साथ-साथ बने आउटपुट को सेव नहीं करता. इसके बजाय, यह इस काम के लिए अलग आउटपुट ट्री का इस्तेमाल करता है. |
Bazel टेस्ट
ये फ़्लैग, Bazel टेस्ट से जुड़े हैं
| झंडा | ब्यौरा |
|---|---|
|
इसकी वजह से, Java टेस्ट को डीबगर कनेक्शन के कनेक्ट होने का इंतज़ार करना पड़ता है. |
|
टेस्ट कितनी बार चलाने हैं. उदाहरण के लिए, टेस्ट को N बार चलाने के लिए, --runs_per_test=N जोड़ें. इससे, गड़बड़ी वाले टेस्ट को डीबग करने और यह देखने में मदद मिल सकती है कि किसी समस्या को ठीक करने से, टेस्ट लगातार पास होता है या नहीं.
|
|
यह फ़्लैग, किसी एक टेस्ट के तरीके को दोहराते समय खास तौर पर मददगार होता है. जैसे, जब आपके किए गए बदलाव की वजह से कोई टेस्ट पूरा न हो पाए. टेस्ट सुइट में मौजूद सभी टेस्ट के तरीकों को फिर से चलाने के बजाय, सिर्फ़ उन टेस्ट पर फ़ोकस किया जा सकता है जो पास नहीं हुए. इससे, फ़ीडबैक जल्दी मिलता है और डीबग करने की प्रोसेस ज़्यादा बेहतर तरीके से होती है. रीयल-टाइम टेस्ट आउटपुट के लिए, इस फ़्लैग का इस्तेमाल अक्सर --test_output=streamed के साथ किया जाता है.
|
|
आउटपुट मोड के बारे में बताता है. डिफ़ॉल्ट रूप से, Bazel टेस्ट आउटपुट को स्थानीय लॉग फ़ाइलों में कैप्चर करता है. किसी गड़बड़ी वाले टेस्ट को दोहराते समय, आम तौर पर --test_output=streamed का इस्तेमाल करके, टेस्ट का आउटपुट रीयल टाइम में देखा जाता है.
|
Bazel run
ये फ़्लैग, Bazel run से जुड़े हैं.
| झंडा | ब्यौरा |
|---|---|
|
इसकी मदद से, एक्सीक्यूटेबल को शुरू करने का तरीका बदला जा सकता है. उदाहरण के लिए, --run_under="strace -c" का इस्तेमाल आम तौर पर डीबग करने के लिए किया जाता है.
|
उपयोगकर्ता के हिसाब से bazelrc के विकल्प
नीचे दिए गए फ़्लैग, उपयोगकर्ता के हिसाब से .bazelrc के विकल्पों से जुड़े हैं.
| झंडा | ब्यौरा |
|---|---|
|
किसी डायरेक्ट्री का पाथ, जहां Bazel कार्रवाइयों और कार्रवाइयों के आउटपुट को पढ़ और लिख सकता है.
अगर डायरेक्ट्री मौजूद नहीं है, तो उसे बनाया जाएगा.
एक से ज़्यादा शाखाओं या फ़ाइल फ़ोल्डर के बीच, बिल्ड आर्टफ़ैक्ट शेयर किए जा सकते हैं. साथ ही, अपने निर्देश में --disk_cache=<path> जोड़कर, Bazel बिल्ड की स्पीड को बढ़ाया जा सकता है.
|
|
एक साथ चलने वाली जॉब की संख्या. आम तौर पर, रिमोट तरीके से प्रोग्राम चलाने के लिए ही ऐसा करना ज़रूरी होता है. ऐसा तब होता है, जब रिमोट बिल्ड क्लस्टर, स्थानीय कंप्यूटर में मौजूद कोर की तुलना में ज़्यादा जॉब चलाता है. |
|
यह तय करता है कि स्थानीय तौर पर चल रही कार्रवाइयों के लिए, सीपीयू या रैम का कितना इस्तेमाल किया जाए. |
|
इससे सैंडबॉक्स, इस पाथ के नीचे अपनी सैंडबॉक्स डायरेक्ट्री बना सकता है. डिफ़ॉल्ट रूप से, Bazel स्थानीय कार्रवाइयों को सैंडबॉक्स में चलाता है. इससे बिल्ड में कुछ ओवरहेड जुड़ जाता है. |
प्रोजेक्ट के हिसाब से bazelrc के विकल्प
यहां दिए गए फ़्लैग, प्रोजेक्ट के हिसाब से .bazelrc के विकल्पों से जुड़े हैं.
| झंडा | ब्यौरा |
|---|---|
|
अगर कोई जांच पूरी नहीं होती है, तो तय की गई संख्या तक हर जांच को फिर से आज़माएं. यह सुविधा, लगातार इंटिग्रेशन के लिए खास तौर पर मददगार है. जिन टेस्ट को पास करने के लिए एक से ज़्यादा कोशिशें करनी पड़ती हैं उन्हें टेस्ट की खास जानकारी में FLAKY के तौर पर मार्क किया जाता है. |
|
कैश मेमोरी वाले एंडपॉइंट का यूआरआई. रिमोट कैश मेमोरी सेट अप करना, Bazel के बिल्ड को तेज़ करने का एक बेहतरीन तरीका हो सकता है. इसे लोकल डिस्क कैश के साथ जोड़ा जा सकता है. |
|
--remote_download_outputs सेटिंग के बावजूद, इस पैटर्न से मेल खाने वाले रिमोट बिल्ड आउटपुट को डाउनलोड करने के लिए फ़ोर्स करें. इस फ़्लैग को दोहराकर, कई पैटर्न तय किए जा सकते हैं.
|
|
रिमोट तौर पर एक्सीक्यूशन करने वाले एंडपॉइंट का HOST या HOST:PORT. अगर रिमोट तौर पर निर्देशों को लागू करने की सेवा का इस्तेमाल किया जा रहा है, तो इसे पास करें. आपको अक्सर --remote_instance_name=<name> जोड़ना पड़ेगा.
|
|
रिमोट एक्ज़ीक्यूशन एपीआई में instance_name के तौर पर पास की जाने वाली वैल्यू.
|
|
अगर तय किया गया है, तो Bazel से जनरेट किए गए हर मैसेज में एक टाइमस्टैंप जोड़ा जाता है. इससे यह पता चलता है कि मैसेज कब दिखाया गया था. यह सीआई सिस्टम के लिए फ़ायदेमंद है, ताकि यह तुरंत समझा जा सके कि किस चरण में कितना समय लगा. |
|
रिमोट तरीके से प्रोसेस करने पर भी, कुछ बिल्ड ऐक्शन को स्थानीय तौर पर चलाने में ज़्यादा समय नहीं लगता. यह कई बातों पर निर्भर करता है, जैसे कि आपके बिल्ड क्लस्टर की क्षमता, इंटरनेट की स्पीड, और इंटरनेट में होने वाली देरी. |