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

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

नाइटली · 9.2 · 9.1 · 9.0 · 8.7 · 8.6

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 सर्वर के लिए, रैम के इस्तेमाल की सीमा तय करता है. उदाहरण के लिए, यहां 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 जोड़ें.