कमांड लाइन फ़्लैग की Bazel की लंबी सूची को नेविगेट करना मुश्किल हो सकता है. इस पेज पर, उन सबसे ज़रूरी फ़्लैग के बारे में बताया गया है जिनके बारे में आपको जानना चाहिए.
काम के सामान्य विकल्प
इन फ़्लैग को कमांड लाइन पर साफ़ तौर पर सेट किया जाना चाहिए.
| फ़्लैग | ब्यौरा |
|---|---|
|
.bazelrc फ़ाइल में, फ़्लैग को कॉन्फ़िगरेशन में व्यवस्थित किया जा सकता है. जैसे, डीबग करने या रिलीज़ बिल्ड के लिए. Additional configuration groups can
be selected with --config=<group>.
|
|
Bazel को बिल्ड और टेस्ट के एक्ज़ीक्यूशन को जारी रखने की पूरी कोशिश करनी चाहिए. डिफ़ॉल्ट रूप से, Bazel तुरंत फ़ेल हो जाता है. |
|
रिमोट एक्ज़ीक्यूशन या कैशिंग (डिस्क और रिमोट, दोनों) का इस्तेमाल करते समय, Bazel को यह बताया जा सकता है कि आपको बिल्ड के सभी (इंटरमीडिएट) आर्टफ़ैक्ट डाउनलोड करने हैं. इसके लिए, यह तरीका अपनाएं:
--remote_download_outputs=all |
|
बाइनरी में बिल्ड की जानकारी (उपयोगकर्ता, टाइमस्टैंप) जोड़ता है. |
बिल्ड और टेस्ट से जुड़ी समस्याएं ढूंढना
इन फ़्लैग की मदद से, Bazel के बिल्ड या टेस्ट से जुड़ी गड़बड़ियों को बेहतर तरीके से समझा जा सकता है.
| फ़्लैग | ब्यौरा |
|---|---|
|
इससे पता चलता है कि उपयोगकर्ता, मशीन या प्रोजेक्ट के लिए तय की गई .bazelrc फ़ाइलों के ज़रिए, कौनसे फ़्लैग अपने-आप सेट हो जाते हैं. |
|
डिफ़ॉल्ट रूप से, Bazel लॉग स्पैम को रोकने की कोशिश करता है. साथ ही, कमांड लाइन पर अनुरोध किए गए पैकेज और सब-पैकेज के लिए, सिर्फ़ कंपाइलर की चेतावनियां और Starlark डीबग आउटपुट प्रिंट करता है. फ़िल्टर करने की सुविधा बंद करने के लिए, --auto_output_filter=none सेट करें.
|
|
इससे सैंडबॉक्सिंग से जुड़ी गड़बड़ियों के बारे में ज़्यादा जानकारी मिलती है. Bazel, डिफ़ॉल्ट रूप से बिल्ड को सैंडबॉक्स क्यों करता है और क्या सैंडबॉक्स किया जाता है, इस बारे में जानने के लिए, सैंडबॉक्सिंग से जुड़ा हमारा दस्तावेज़ देखें. |
|
इसमें हर उस कमांड की पूरी सूची दिखती है जिसे Bazel, बिल्ड के दौरान रन करता है. भले ही, वह कमांड सफल हो या फ़ेल |
स्टार्टअप
| फ़्लैग | ब्यौरा |
|---|---|
|
.bazelrc फ़ाइलों में, Bazel के डिफ़ॉल्ट विकल्प तय किए जा सकते हैं. अगर
एक से ज़्यादा .bazelrc फ़ाइलें मौजूद हैं, तो यह चुना जा सकता है कि कौनसी
.bazelrc फ़ाइल इस्तेमाल की जाए. इसके लिए, --bazelrc=<path to
the .bazelrc file> जोड़ें.
|
|
इससे 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 रन
ये फ़्लैग, Bazel रन से जुड़े हैं.
| फ़्लैग | ब्यौरा |
|---|---|
|
इससे तय होता है कि एक्ज़ीक्यूटेबल को कैसे शुरू किया जाए. उदाहरण के लिए, --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 से जनरेट होने वाले हर मैसेज में टाइमस्टैंप जोड़ा जाता है. इससे पता चलता है कि मैसेज कब दिखाया गया था. सीआई सिस्टम पर, यह सुविधा यह समझने के लिए काम की है कि किस चरण में कितना समय लगा. |
|
रिमोट एक्ज़ीक्यूशन के बावजूद, कुछ बिल्ड ऐक्शन को लोकल तौर पर रन करना ज़्यादा तेज़ हो सकता है. यह आपके बिल्ड क्लस्टर की क्षमता, नेटवर्क की स्पीड, और नेटवर्क में होने वाली देरी जैसे फ़ैक्टर पर निर्भर करता है. |