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

कमांड लाइन फ़्लैग की 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_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

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