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

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_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	अगर किसी भी जांच में कोई गड़बड़ी होती है, तो तय की गई संख्या तक हर जांच को फिर से आज़माएं. यह सुविधा, लगातार इंटिग्रेशन के लिए खास तौर पर मददगार है. जिन टेस्ट को पास करने के लिए एक से ज़्यादा कोशिशें करनी पड़ती हैं उन्हें टेस्ट की खास जानकारी में अमान्य के तौर पर मार्क किया जाता है.
--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 जोड़ें.