Bazel के कमांड-लाइन फ़्लैग की लंबी सूची को नेविगेट करना मुश्किल हो सकता है. इस पेज पर, सबसे ज़रूरी फ़्लैग के बारे में बताया गया है.
काम के सामान्य विकल्प
यहां दिए गए फ़्लैग, कमांड लाइन पर साफ़ तौर पर सेट किए जाने चाहिए.
| झंडा | ब्यौरा |
|---|---|
|
.bazelrc फ़ाइल में मौजूद फ़्लैग को कॉन्फ़िगरेशन में व्यवस्थित किया जा सकता है. जैसे, डीबग करने या रिलीज़ बिल्ड के लिए फ़्लैग. --config=<group> की मदद से, अतिरिक्त कॉन्फ़िगरेशन ग्रुप चुने जा सकते हैं.
|
|
Bazel को, जितना हो सके उतना बिल्ड और टेस्ट एक्ज़ीक्यूशन जारी रखने की कोशिश करनी चाहिए. डिफ़ॉल्ट रूप से, Bazel तुरंत फ़ेल हो जाता है. |
|
रिमोट एक्ज़ीक्यूशन या कैश मेमोरी (डिस्क और रिमोट, दोनों) का इस्तेमाल करते समय, Bazel को यह सूचना दी जा सकती है कि आपको सभी (इंटरमीडिएट) बिल्ड आर्टफ़ैक्ट डाउनलोड करने हैं. इसके लिए, यह तरीका अपनाएं:
--remote_download_outputs=all |
|
यह बाइनरी में बिल्ड की जानकारी (उपयोगकर्ता, टाइमस्टैंप) जोड़ता है. |
बिल्ड और टेस्ट से जुड़ी समस्याओं का पता लगाना
यहां दिए गए फ़्लैग से, आपको Bazel बिल्ड या टेस्ट से जुड़ी गड़बड़ियों को बेहतर तरीके से समझने में मदद मिल सकती है.
| झंडा | ब्यौरा |
|---|---|
|
इससे पता चलता है कि उपयोगकर्ता की तय की गई, मशीन की तय की गई या प्रोजेक्ट की तय की गई .bazelrc फ़ाइलों के ज़रिए कौनसे फ़्लैग अपने-आप सेट हो जाते हैं. |
|
डिफ़ॉल्ट रूप से, Bazel लॉग स्पैम को रोकने की कोशिश करता है. साथ ही, यह सिर्फ़ कंपाइलर की चेतावनियां और कमांड लाइन पर अनुरोध किए गए पैकेज और सब-पैकेज के लिए, Starlark डीबग आउटपुट प्रिंट करता है. सभी फ़िल्टरिंग बंद करने के लिए, --auto_output_filter=none पर सेट करें.
|
|
इसकी मदद से, सैंडबॉक्सिंग से जुड़ी गड़बड़ियों की ज़्यादा जानकारी देखी जा सकती है. Bazel, डिफ़ॉल्ट रूप से बिल्ड को सैंडबॉक्स क्यों करता है और क्या सैंडबॉक्स किया जाता है, इस बारे में जानने के लिए सैंडबॉक्सिंग से जुड़ा हमारा दस्तावेज़ देखें. |
|
यह विकल्प, Bazel की उन सभी कमांड की पूरी सूची दिखाता है जिन्हें Bazel, बिल्ड के दौरान चलाता है. भले ही, बिल्ड पूरा हो या न हो |
स्टार्टअप
| झंडा | ब्यौरा |
|---|---|
|
.bazelrc फ़ाइलों में, Bazel के डिफ़ॉल्ट विकल्प तय किए जा सकते हैं. अगर एक से ज़्यादा .bazelrc फ़ाइलें मौजूद हैं, तो --bazelrc=<path to
the .bazelrc file> जोड़कर यह चुना जा सकता है कि कौनसी .bazelrc फ़ाइल इस्तेमाल की जाएगी.
|
|
Bazel सर्वर के लिए RAM के इस्तेमाल की सीमा तय करता है.
उदाहरण के लिए, यहां Bazel के हीप साइज़ को 3 जीबी तक सीमित किया गया है:
--host_jvm_args=-Xmx3g |
|
यह विकल्प, Bazel के आउटपुट ट्री को कंट्रोल करता है. Bazel, बिल्ड आउटपुट को सोर्स ट्री में सेव नहीं करता. इनमें लॉग भी शामिल हैं. इसके बजाय, यह इस काम के लिए अलग आउटपुट ट्री का इस्तेमाल करता है. |
Bazel टेस्ट
नीचे दिए गए फ़्लैग, Bazel टेस्ट से जुड़े हैं
| झंडा | ब्यौरा |
|---|---|
|
इस विकल्प का इस्तेमाल करने पर, Java टेस्ट तब तक नहीं किए जाते, जब तक डीबगर कनेक्ट नहीं हो जाता. |
|
टेस्ट को कितनी बार चलाना है. उदाहरण के लिए, टेस्ट को N बार चलाने के लिए, --runs_per_test=N जोड़ें. इससे, फ़्लेकी टेस्ट को डीबग करने में मदद मिल सकती है. साथ ही, यह देखा जा सकता है कि किसी समस्या को ठीक करने से, टेस्ट लगातार पास हो रहा है या नहीं.
|
|
यह फ़्लैग तब खास तौर पर काम आता है, जब एक ही टेस्ट के तरीके को बार-बार आज़माया जा रहा हो. जैसे, जब आपके किए गए बदलाव की वजह से कोई टेस्ट काम न करे. टेस्ट सुइट में मौजूद सभी टेस्ट के तरीकों को फिर से चलाने के बजाय, सिर्फ़ उन टेस्ट पर फ़ोकस किया जा सकता है जो पास नहीं हुए. इससे तेज़ी से फ़ीडबैक मिलता है और डीबग करने में आसानी होती है. इस फ़्लैग का इस्तेमाल अक्सर --test_output=streamed के साथ किया जाता है, ताकि टेस्ट का आउटपुट रीयल-टाइम में मिल सके.
|
|
इससे आउटपुट मोड के बारे में पता चलता है. डिफ़ॉल्ट रूप से, Bazel टेस्ट के आउटपुट को स्थानीय लॉग फ़ाइलों में सेव करता है. जब किसी गड़बड़ी वाले टेस्ट को ठीक किया जा रहा हो, तब आम तौर पर आपको --test_output=streamed का इस्तेमाल करना चाहिए, ताकि टेस्ट का आउटपुट रीयल टाइम में देखा जा सके.
|
Bazel run
नीचे दिए गए फ़्लैग, Bazel रन से जुड़े हैं.
| झंडा | ब्यौरा |
|---|---|
|
इससे, एक्ज़ीक्यूटेबल को शुरू करने का तरीका बदल जाता है. उदाहरण के लिए, --run_under="strace -c" का इस्तेमाल आम तौर पर डीबग करने के लिए किया जाता है.
|
उपयोगकर्ता के हिसाब से bazelrc के विकल्प
यहां दिए गए फ़्लैग, उपयोगकर्ता के हिसाब से .bazelrc फ़ाइल में मौजूद विकल्पों से जुड़े हैं.
| झंडा | ब्यौरा |
|---|---|
|
यह उस डायरेक्ट्री का पाथ होता है जहाँ Bazel, कार्रवाइयाँ और कार्रवाई के आउटपुट को पढ़ और लिख सकता है.
अगर डायरेक्ट्री मौजूद नहीं है, तो उसे बनाया जाएगा.
एक से ज़्यादा ब्रांच या फ़ाइल फ़ोल्डर के बीच, बिल्ड आर्टफ़ैक्ट शेयर किए जा सकते हैं. साथ ही, अपनी कमांड में --disk_cache=<path> जोड़कर, Bazel बिल्ड की प्रोसेस को तेज़ किया जा सकता है.
|
|
एक साथ चलाए जाने वाले जॉब की संख्या. आम तौर पर, इसकी ज़रूरत सिर्फ़ तब होती है, जब रिमोट एक्ज़ीक्यूशन का इस्तेमाल किया जा रहा हो. इसमें रिमोट बिल्ड क्लस्टर, आपके लोकल सिस्टम में मौजूद कोर की तुलना में ज़्यादा जॉब एक्ज़ीक्यूट करता है. |
|
इससे यह तय किया जाता है कि स्थानीय तौर पर चल रही कार्रवाइयों के लिए, सीपीयू या रैम का कितना इस्तेमाल किया जाए. |
|
इस पाथ के नीचे सैंडबॉक्स को अपनी सैंडबॉक्स डायरेक्ट्री बनाने की अनुमति देता है. डिफ़ॉल्ट रूप से, Bazel लोकल ऐक्शन को सैंडबॉक्स में एक्ज़ीक्यूट करता है. इससे बिल्ड में कुछ ओवरहेड जुड़ जाता है. |
प्रोजेक्ट के हिसाब से bazelrc के विकल्प
ये फ़्लैग, प्रोजेक्ट के हिसाब से .bazelrc फ़ाइल में मौजूद विकल्पों से जुड़े हैं.
| झंडा | ब्यौरा |
|---|---|
|
अगर कोई टेस्ट पूरा नहीं होता है, तो उसे तय की गई संख्या तक फिर से आज़माएं. यह सुविधा, खास तौर पर लगातार इंटिग्रेशन के लिए मददगार होती है. जिन टेस्ट को पास करने के लिए एक से ज़्यादा बार कोशिश करनी पड़ती है उन्हें टेस्ट की खास जानकारी में FLAKY के तौर पर मार्क किया जाता है. |
|
कैशिंग एंडपॉइंट का यूआरआई. रिमोट कैशिंग सेट अप करने से, Bazel के बिल्ड को तेज़ी से पूरा किया जा सकता है. इसे लोकल डिस्क कैश के साथ जोड़ा जा सकता है. |
|
इस पैटर्न से मेल खाने वाले पाथ के रिमोट बिल्ड आउटपुट को डाउनलोड करने के लिए मजबूर करें. भले ही, --remote_download_outputs सेटिंग कुछ भी हो. इस फ़्लैग को दोहराकर, एक से ज़्यादा पैटर्न तय किए जा सकते हैं.
|
|
HOST या रिमोट एक्ज़ीक्यूशन एंडपॉइंट का HOST:PORT. अगर रिमोट एक्ज़ीक्यूशन सेवा का इस्तेमाल किया जा रहा है, तो इसे पास करें. आपको अक्सर --remote_instance_name=<name> जोड़ना होगा.
|
|
रिमोट एक्ज़ीक्यूशन एपीआई में instance_name के तौर पर पास की जाने वाली वैल्यू.
|
|
अगर बताया गया है, तो Bazel से जनरेट हुए हर मैसेज में टाइमस्टैंप जोड़ा जाता है. इससे यह पता चलता है कि मैसेज कब दिखाया गया था. यह सीआई सिस्टम पर यह समझने के लिए काम आता है कि किस चरण में कितना समय लगा. |
|
रिमोट एक्ज़ीक्यूशन की सुविधा चालू होने पर भी, कुछ बिल्ड ऐक्शन को स्थानीय तौर पर तेज़ी से चलाया जा सकता है. यह कई बातों पर निर्भर करता है. जैसे, आपके बिल्ड क्लस्टर की क्षमता, नेटवर्क की स्पीड, और नेटवर्क में होने वाली देरी. |