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

कमांड लाइन फ़्लैग की 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, डिफ़ॉल्ट रूप से बिल्ड को सैंडबॉक्स क्यों करता है और क्या सैंडबॉक्स किया जाता है, इस बारे में जानने के लिए, सैंडबॉक्सिंग से जुड़ा हमारा दस्तावेज़ देखें.

--subcommands (-s)

इसमें हर उस कमांड की पूरी सूची दिखती है जिसे Bazel, बिल्ड के दौरान रन करता है. भले ही, वह कमांड सफल हो या फ़ेल

स्टार्टअप

फ़्लैग ब्यौरा

--bazelrc

.bazelrc फ़ाइलों में, Bazel के डिफ़ॉल्ट विकल्प तय किए जा सकते हैं. अगर एक से ज़्यादा .bazelrc फ़ाइलें मौजूद हैं, तो यह चुना जा सकता है कि कौनसी .bazelrc फ़ाइल इस्तेमाल की जाए. इसके लिए, --bazelrc=<path to the .bazelrc file> जोड़ें.

--host_jvm_args

इससे, Bazel सर्वर के इस्तेमाल की जाने वाली रैम की मात्रा सीमित हो जाती है. उदाहरण के लिए, इससे Bazel के हीप साइज़ को 3जीबी तक सीमित किया जा सकता है:
--host_jvm_args=-Xmx3g

--output_base

इससे 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 रन

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

फ़्लैग ब्यौरा

--run_under

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

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

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

फ़्लैग ब्यौरा

--disk_cache

यह उस डायरेक्ट्री का पाथ है जहां Bazel, कार्रवाइयों और कार्रवाई के आउटपुट को पढ़ और लिख सकता है. अगर डायरेक्ट्री मौजूद नहीं है, तो उसे बनाया जाएगा. अपने कमांड में --disk_cache=<path> जोड़कर, एक से ज़्यादा ब्रांच या वर्कस्पेस के बीच बिल्ड आर्टफ़ैक्ट शेयर किए जा सकते हैं. साथ ही, Bazel के बिल्ड की स्पीड बढ़ाई जा सकती है.

--jobs

एक साथ रन की जाने वाली जॉब की संख्या. आम तौर पर, इसकी ज़रूरत सिर्फ़ रिमोट एक्ज़ीक्यूशन का इस्तेमाल करते समय होती है. इसमें, रिमोट बिल्ड क्लस्टर, लोकल तौर पर मौजूद कोर से ज़्यादा जॉब एक्ज़ीक्यूट करता है.

--local_resources

इससे, लोकल तौर पर रन की जाने वाली कार्रवाइयों के लिए, सीपीयू या रैम के इस्तेमाल की सीमा तय की जा सकती है.

--sandbox_base

इससे सैंडबॉक्स, इस पाथ के तहत अपनी सैंडबॉक्स डायरेक्ट्री बना सकता है. डिफ़ॉल्ट रूप से, Bazel लोकल ऐक्शन को सैंडबॉक्स में एक्ज़ीक्यूट करता है. इससे बिल्ड में कुछ ओवरहेड जुड़ जाता है.

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

रिमोट एक्ज़ीक्यूशन के बावजूद, कुछ बिल्ड ऐक्शन को लोकल तौर पर रन करना ज़्यादा तेज़ हो सकता है. यह आपके बिल्ड क्लस्टर की क्षमता, नेटवर्क की स्पीड, और नेटवर्क में होने वाली देरी जैसे फ़ैक्टर पर निर्भर करता है.