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

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

नाइटली रिलीज़ · 9.0 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 7.7

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

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

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

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

झंडा	ब्यौरा
--config	.bazelrc फ़ाइल में मौजूद फ़्लैग को कॉन्फ़िगरेशन में व्यवस्थित किया जा सकता है. जैसे, डीबग करने या रिलीज़ बिल्ड के लिए फ़्लैग. --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 की उन सभी कमांड की पूरी सूची दिखाता है जिन्हें Bazel, बिल्ड के दौरान चलाता है. भले ही, बिल्ड पूरा हो या न हो

स्टार्टअप

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

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

नीचे दिए गए फ़्लैग, Bazel रन से जुड़े हैं.

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

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

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

झंडा	ब्यौरा
--disk_cache	उस डायरेक्ट्री का पाथ जहां Bazel, कार्रवाइयों और कार्रवाई के आउटपुट को पढ़ और लिख सकता है. अगर डायरेक्ट्री मौजूद नहीं है, तो उसे बनाया जाएगा. एक से ज़्यादा ब्रांच या वर्कस्पेस के बीच बिल्ड आर्टफ़ैक्ट शेयर किए जा सकते हैं. साथ ही, अपनी कमांड में --disk_cache=<path> जोड़कर, Bazel बिल्ड की प्रोसेस को तेज़ किया जा सकता है.
--jobs	एक साथ चलाए जाने वाले जॉब की संख्या. आम तौर पर, इसकी ज़रूरत सिर्फ़ तब होती है, जब रिमोट एक्ज़ीक्यूशन का इस्तेमाल किया जा रहा हो. इसमें रिमोट बिल्ड क्लस्टर, आपके लोकल सिस्टम में मौजूद कोर की तुलना में ज़्यादा जॉब एक्ज़ीक्यूट करता है.
--local_resources	इससे यह तय किया जाता है कि स्थानीय तौर पर चल रही कार्रवाइयों के लिए, सीपीयू या रैम का कितना इस्तेमाल किया जाए. ध्यान दें: इससे सीपीयू या रैम की उस मात्रा पर कोई असर नहीं पड़ता जिसका इस्तेमाल 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 से जनरेट हुए हर मैसेज में टाइमस्टैंप जोड़ा जाता है. इससे यह पता चलता है कि मैसेज कब दिखाया गया था. यह CI सिस्टम पर यह समझने के लिए काम आता है कि किस चरण में कितना समय लगा.
--spawn_strategy	रिमोट एक्ज़ीक्यूशन की सुविधा चालू होने पर भी, कुछ बिल्ड ऐक्शन को स्थानीय तौर पर तेज़ी से चलाया जा सकता है. यह आपके बिल्ड क्लस्टर की क्षमता, नेटवर्क की स्पीड, और नेटवर्क में होने वाली देरी जैसे फ़ैक्टर पर निर्भर करता है. अहम जानकारी: स्थानीय और रिमोट, दोनों जगहों पर कार्रवाइयां करने और तेज़ी से नतीजे पाने के लिए, अपनी बिल्ड कमांड में --spawn_strategy=dynamic जोड़ें.