बेज़ल फ़्लैग की चीट शीट

समस्या की शिकायत करें सोर्स देखें

Nightly · 9.2 · 9.1 · 9.0 · 8.7 · 8.6

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

सलाह: कमांड लाइन रेफ़रंस में, फ़्लैग की एंट्री पर जाने के लिए, टेबल में फ़्लैग का नाम चुनें.

काम के सामान्य विकल्प

इन फ़्लैग को कमांड लाइन पर साफ़ तौर पर सेट किया जाना चाहिए.

फ़्लैग	ब्यौरा
--config	.bazelrc फ़ाइल में, फ़्लैग को कॉन्फ़िगरेशन में व्यवस्थित किया जा सकता है. जैसे, डीबग करने या रिलीज़ बिल्ड के लिए कॉन्फ़िगरेशन. Additional configuration groups can be selected with --config=<group>.
--keep_going	Bazel को बिल्ड और टेस्ट के एक्ज़ीक्यूशन को जारी रखने की पूरी कोशिश करनी चाहिए. डिफ़ॉल्ट रूप से, Bazel तुरंत फ़ेल हो जाता है.
--remote_download_outputs	रिमोट एक्ज़ीक्यूशन या कैशिंग (डिस्क और रिमोट, दोनों) का इस्तेमाल करते समय, Bazel को यह बताया जा सकता है कि आपको बिल्ड के सभी (इंटरमीडिएट) आर्टफ़ैक्ट डाउनलोड करने हैं. इसके लिए, यह तरीका अपनाएं: --remote_download_outputs=all डिफ़ॉल्ट रूप से, Bazel सिर्फ़ टॉप-लेवल आर्टफ़ैक्ट डाउनलोड करता है. जैसे, फ़ाइनल बाइनरी और इंटरमीडिएट आर्टफ़ैक्ट, जो लोकल ऐक्शन के लिए ज़रूरी होते हैं.
--stamp	बाइनरी में बिल्ड की जानकारी (उपयोगकर्ता, टाइमस्टैंप) जोड़ता है. ध्यान दें: इससे बिल्ड का समय बढ़ जाता है. इसलिए, इसका इस्तेमाल सिर्फ़ रिलीज़ बिल्ड के लिए किया जाता है.

बिल्ड और टेस्ट की समस्याएं ढूंढना

इन फ़्लैग की मदद से, Bazel के बिल्ड या टेस्ट की गड़बड़ियों को बेहतर तरीके से समझा जा सकता है.

फ़्लैग	ब्यौरा
--announce_rc	इससे पता चलता है कि उपयोगकर्ता, मशीन या प्रोजेक्ट की ओर से तय की गई .bazelrc फ़ाइलों के ज़रिए, कौनसे फ़्लैग अपने-आप सेट होते हैं.
--auto_output_filter	डिफ़ॉल्ट रूप से, Bazel लॉग स्पैम को रोकने की कोशिश करता है. साथ ही, कमांड लाइन पर अनुरोध किए गए पैकेज और सब-पैकेज के लिए, सिर्फ़ कंपाइलर की चेतावनियां और Starlark डीबग आउटपुट प्रिंट करता है. सभी फ़िल्टरिंग बंद करने के लिए, सेट करें --auto_output_filter=none.
--sandbox_debug	इससे सैंडबॉक्सिंग की गड़बड़ियों के बारे में ज़्यादा जानकारी मिलती है. Bazel, डिफ़ॉल्ट रूप से बिल्ड को सैंडबॉक्स क्यों करता है और क्या सैंडबॉक्स किया जाता है, इस बारे में जानने के लिए, सैंडबॉक्सिंग से जुड़ा हमारा दस्तावेज़ देखें. सलाह: अगर आपको लगता है कि गड़बड़ी, सैंडबॉक्सिंग की वजह से हो सकती है, अस्थायी तौर पर सैंडबॉक्सिंग बंद करके देखें. इसके लिए, अपने कमांड में --spawn_strategy=standalone जोड़ें.
--subcommands (-s)	इसमें, हर उस कमांड की पूरी सूची दिखती है जिसे Bazel, बिल्ड के दौरान चलाता है. भले ही, वह कमांड सफल हो या फ़ेल

स्टार्टअप

चेतावनी: स्टार्टअप फ़्लैग को कमांड से पहले पास करना ज़रूरी है. ऐसा करने से सर्वर रीस्टार्ट हो जाता है. इन फ़्लैग को टॉगल करते समय सावधानी बरतें.

फ़्लैग	ब्यौरा
--bazelrc	.bazelrc फ़ाइलों में, Bazel के डिफ़ॉल्ट विकल्प तय किए जा सकते हैं. अगर एक से ज़्यादा .bazelrc फ़ाइलें मौजूद हैं, तो यह चुना जा सकता है कि कौनसी .bazelrc फ़ाइल इस्तेमाल की जाए. इसके लिए, --bazelrc=<path to the .bazelrc file> जोड़ें. सलाह: --bazelrc=dev/null जोड़ने पर, .bazelrc फ़ाइलों को खोजने की सुविधा बंद हो जाती है. यह उन स्थितियों के लिए सही है जहां आपको साफ़-सुथरा बिल्ड एनवायरमेंट चाहिए. जैसे, रिलीज़ बिल्ड. साथ ही, अनचाहे कॉन्फ़िगरेशन में बदलावों को रोकना हो जो .bazelrc फ़ाइलों से होते हैं
--host_jvm_args	इससे, Bazel सर्वर के इस्तेमाल की जाने वाली रैम की मात्रा सीमित हो जाती है. उदाहरण के लिए, इससे Bazel के हीप साइज़ को 3जीबी तक सीमित किया जा सकता है: --host_jvm_args=-Xmx3g ध्यान दें: Java Virtual Machine (JVM) के लिए, ज़्यादा से ज़्यादा हीप साइज़ सेट करने के लिए -Xmx का इस्तेमाल किया जाता है. हीप, मेमोरी का वह हिस्सा होता है जहां ऑब्जेक्ट असाइन किए जाते हैं. इस विकल्प के लिए सही फ़ॉर्मैट -Xmx<size> है. इसमें <size> ज़्यादा से ज़्यादा हीप साइज़ होता है. इसे किसी यूनिट के साथ तय किया जाता है. जैसे: मेगाबाइट के लिए m गीगाबाइट के लिए g किलोबाइट के लिए k
--output_base	इससे Bazel के आउटपुट ट्री को कंट्रोल किया जा सकता है. Bazel, बिल्ड के आउटपुट को सोर्स ट्री में सेव नहीं करता. इनमें लॉग भी शामिल हैं. इसके बजाय, वह इसके लिए अलग आउटपुट ट्री का इस्तेमाल करता है. सलाह: एक Bazel वर्कस्पेस में एक से ज़्यादा आउटपुट बेस का इस्तेमाल करने से, एक साथ कई Bazel सर्वर चलाए जा सकते हैं. यह, विश्लेषण थ्रैशिंग से बचने की कोशिश करते समय काम आ सकता है. ज़्यादा जानकारी के लिए, देखें आउटपुट बेस चुनना.

Bazel के टेस्ट

ये फ़्लैग, Bazel के टेस्ट से जुड़े हैं

फ़्लैग	ब्यौरा
--java_debug	इससे Java के टेस्ट, एक्ज़ीक्यूट होने से पहले डीबगर कनेक्शन का इंतज़ार करते हैं.
--runs_per_test	टेस्ट को कितनी बार चलाना है. उदाहरण के लिए, टेस्ट को N बार चलाने के लिए, जोड़ें --runs_per_test=N. यह, फ़्लेकी टेस्ट को डीबग करने और यह देखने के लिए काम आ सकता है कि किसी फ़िक्स की वजह से टेस्ट लगातार पास होता है या नहीं.
--test_output	इससे आउटपुट मोड तय होता है. डिफ़ॉल्ट रूप से, Bazel टेस्ट के आउटपुट को लोकल लॉग फ़ाइलों में कैप्चर करता है. जब किसी गड़बड़ी वाले टेस्ट को ठीक किया जाता है, तो आम तौर पर --test_output=streamed का इस्तेमाल किया जाता है, ताकि टेस्ट का आउटपुट रीयल टाइम में देखा जा सके.

Bazel रन

ये फ़्लैग, Bazel रन से जुड़े हैं.

फ़्लैग	ब्यौरा
--run_under	इससे, एक्ज़ीक्यूटेबल को लागू करने का तरीका बदल जाता है. उदाहरण के लिए, डीबग करने के लिए, आम तौर पर --run_under="strace -c" का इस्तेमाल किया जाता है.

उपयोगकर्ता के हिसाब से bazelrc के विकल्प

ये फ़्लैग, उपयोगकर्ता के हिसाब से .bazelrc के विकल्पों से जुड़े हैं.

फ़्लैग	ब्यौरा
--disk_cache	यह उस डायरेक्ट्री का पाथ है जहां Bazel, कार्रवाइयों और कार्रवाई के आउटपुट को पढ़ और लिख सकता है. अगर डायरेक्ट्री मौजूद नहीं है, तो उसे बनाया जाएगा. अपने कमांड में --disk_cache=<path> जोड़कर, एक से ज़्यादा ब्रांच या वर्कस्पेस के बीच बिल्ड आर्टफ़ैक्ट शेयर किए जा सकते हैं. साथ ही, Bazel के बिल्ड की स्पीड बढ़ाई जा सकती है.
--jobs	एक साथ कितनी जॉब चलानी हैं. आम तौर पर, इसकी ज़रूरत सिर्फ़ रिमोट एक्ज़ीक्यूशन का इस्तेमाल करते समय होती है. इसमें, रिमोट बिल्ड क्लस्टर, लोकल तौर पर मौजूद कोर से ज़्यादा जॉब एक्ज़ीक्यूट करता है.
--local_resources	इससे, लोकल तौर पर चल रही कार्रवाइयों के लिए, सीपीयू या रैम के इस्तेमाल की सीमा तय की जा सकती है. ध्यान दें: इससे, Bazel सर्वर के सीपीयू या रैम के इस्तेमाल की मात्रा पर कोई असर नहीं पड़ता. Bazel सर्वर, विश्लेषण और बिल्ड ऑर्केस्ट्रेशन जैसे टास्क के लिए सीपीयू या रैम का इस्तेमाल करता है.
--sandbox_base	इससे सैंडबॉक्स, इस पाथ के तहत अपनी सैंडबॉक्स डायरेक्ट्री बना सकता है. डिफ़ॉल्ट रूप से, Bazel लोकल ऐक्शन को सैंडबॉक्स में एक्ज़ीक्यूट करता है. इससे बिल्ड में कुछ ओवरहेड जुड़ जाता है. सलाह: tmpfs पर कोई पाथ तय करें. जैसे, /run/shm. इससे, आपके बिल्ड या टेस्ट में कई इनपुट फ़ाइलें होने पर, परफ़ॉर्मेंस को बेहतर बनाया जा सकता है.

प्रोजेक्ट के हिसाब से bazelrc के विकल्प

ये फ़्लैग, प्रोजेक्ट के हिसाब से .bazelrc के विकल्पों से जुड़े हैं.

फ़्लैग	ब्यौरा
--flaky_test_attempts	किसी टेस्ट के फ़ेल होने पर, हर टेस्ट को तय की गई संख्या तक फिर से आज़माएं. यह सुविधा, कंटीन्यूअस इंटिग्रेशन के लिए खास तौर पर काम की है. जिन टेस्ट को पास होने के लिए एक से ज़्यादा बार आज़माना पड़ता है उन्हें टेस्ट के सारांश में FLAKY के तौर पर मार्क किया जाता है.
--remote_cache	यह कैशिंग एंडपॉइंट का यूआरआई है. रिमोट कैशिंग सेट अप करने से, Bazel के बिल्ड की स्पीड बढ़ाई जा सकती है. इसे लोकल डिस्क कैश के साथ जोड़ा जा सकता है.
--remote_download_regex	रिमोट बिल्ड के उन आउटपुट को डाउनलोड करने के लिए मजबूर करें जिनका पाथ इस पैटर्न से मेल खाता है. भले ही, --remote_download_outputs सेटिंग कुछ भी हो. इस फ़्लैग को दोहराकर, एक से ज़्यादा पैटर्न तय किए जा सकते हैं.
--remote_executor	यह रिमोट एक्ज़ीक्यूशन एंडपॉइंट का HOST या HOST:PORT है. अगर रिमोट एक्ज़ीक्यूशन सेवा का इस्तेमाल किया जा रहा है, तो इसे पास करें. आपको अक्सर जोड़ने की ज़रूरत पड़ेगी --remote_instance_name=<name>.
--remote_instance_name	रिमोट एक्ज़ीक्यूशन एपीआई में instance_name के तौर पर पास की जाने वाली वैल्यू.
--show-timestamps	अगर यह तय किया जाता है, तो Bazel से जनरेट किए गए हर मैसेज में टाइमस्टैंप जोड़ा जाता है. इससे यह पता चलता है कि मैसेज कब दिखाया गया था. सीआई सिस्टम पर, इससे यह समझने में मदद मिलती है कि किस चरण में कितना समय लगा.
--spawn_strategy	रिमोट एक्ज़ीक्यूशन के बावजूद, कुछ बिल्ड ऐक्शन को लोकल तौर पर चलाना ज़्यादा तेज़ हो सकता है. यह, आपके बिल्ड क्लस्टर की क्षमता, नेटवर्क की स्पीड, और नेटवर्क में होने वाली देरी जैसे फ़ैक्टर पर निर्भर करता है. सलाह: ऐक्शन को लोकल और रिमोट, दोनों तरह से चलाने और तेज़ नतीजे पाने के लिए, --spawn_strategy=dynamic अपने बिल्ड कमांड में जोड़ें.