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

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 किसी बिल्ड के दौरान चलाता है. इससे कोई फ़र्क़ नहीं पड़ता कि बिल्ड पूरा होता है या नहीं

स्टार्टअप

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

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

Bazel run

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

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

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

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

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

प्रोजेक्ट के हिसाब से 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 जोड़ें.