वर्कस्पेस में डिपेंडेंसी को शैडो करना
जब भी हो सके, अपने प्रोजेक्ट में एक वर्शन नीति का इस्तेमाल करें. यह उन डिपेंडेंसी के लिए ज़रूरी है जिन्हें आप इकट्ठा करते हैं और अपनी फ़ाइनल बाइनरी में ले जाते हैं. अन्य मामलों के लिए, डिपेंडेंसी को शैडो किया जा सकता है:
मेरा प्रोजेक्ट/वर्कस्पेस
workspace(name = "myproject")
local_repository(
name = "A",
path = "../A",
)
local_repository(
name = "B",
path = "../B",
)
A/WORKSPACE
workspace(name = "A")
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "testrunner",
urls = ["https://github.com/testrunner/v1.zip"],
sha256 = "...",
)
बी/वर्कस्पेस
workspace(name = "B")
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "testrunner",
urls = ["https://github.com/testrunner/v2.zip"],
sha256 = "..."
)
A और B, दोनों डिपेंडेंसी, testrunner के अलग-अलग वर्शन पर निर्भर करती हैं.
myproject/WORKSPACE में दोनों को अलग-अलग नाम देकर, बिना किसी टकराव के myproject में शामिल करें:
workspace(name = "myproject")
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "testrunner-v1",
urls = ["https://github.com/testrunner/v1.zip"],
sha256 = "..."
)
http_archive(
name = "testrunner-v2",
urls = ["https://github.com/testrunner/v2.zip"],
sha256 = "..."
)
local_repository(
name = "A",
path = "../A",
repo_mapping = {"@testrunner" : "@testrunner-v1"}
)
local_repository(
name = "B",
path = "../B",
repo_mapping = {"@testrunner" : "@testrunner-v2"}
)
हीरे जोड़ने के लिए भी इस तरीके का इस्तेमाल किया जा सकता है. उदाहरण के लिए, अगर A और B
पर एक ही डिपेंडेंसी है, लेकिन इसे अलग-अलग नामों से कॉल करें, तो उन डिपेंडेंसी को myproject/WORKSPACE में जोड़ें.
कमांड लाइन से डेटा स्टोर करने की जगहों को बदलना
कमांड लाइन से, एलान किए गए डेटा स्टोर करने की जगह को लोकल डेटा स्टोर करने की जगह से बदलने के लिए, --override_repository फ़्लैग का इस्तेमाल करें. इस फ़्लैग का इस्तेमाल करने से आपका सोर्स कोड बदले बिना, बाहरी डेटा स्टोर करने की जगहों की सामग्री बदल जाती है.
उदाहरण के लिए, @foo को लोकल डायरेक्ट्री /path/to/local/foo में बदलने के लिए,
--override_repository=foo=/path/to/local/foo फ़्लैग को पास करें.
इस्तेमाल के उदाहरणों में ये शामिल हैं:
- डीबग करने से जुड़ी समस्याएं. उदाहरण के लिए,
http_archiveडेटा स्टोर करने की जगह को किसी लोकल डायरेक्ट्री में बदलने के लिए, जहां ज़्यादा आसानी से बदलाव किए जा सकते हैं. - वेंडरिंग. अगर आप ऐसे एनवायरमेंट में हैं जहां नेटवर्क कॉल नहीं किए जा सकते, तो नेटवर्क पर आधारित डेटा स्टोर करने की जगह के नियमों को ओवरराइड करें, ताकि लोकल डायरेक्ट्री पर ले जाया जा सके.
प्रॉक्सी का इस्तेमाल करना
Bazz, HTTPS_PROXY और HTTP_PROXY एनवायरमेंट वैरिएबल से प्रॉक्सी पते चुनता है. साथ ही, HTTP और HTTPS फ़ाइलों (अगर बताई गई हो) को डाउनलोड करने के लिए इनका इस्तेमाल करता है.
आईपीवी6 के साथ काम करने की सुविधा
सिर्फ़ आईपीवी6 मशीनों पर, Basel बिना किसी बदलाव के डिपेंडेंसी डाउनलोड कर सकता है. हालांकि, ड्यूअल-स्टैक IPv4/IPv6 मशीनों पर Baज़र, Java की तरह ही काम करता है. हालांकि, अगर उसे चालू किया जाता है, तो IPv4 को प्राथमिकता दी जाती है. कुछ मामलों में, उदाहरण के लिए, जब आईपीवी4 नेटवर्क बाहरी पतों को ठीक नहीं कर पाता या ऐक्सेस नहीं कर पाता, तो इसकी वजह से Network
unreachable अपवाद हो सकते हैं और बिल्ड काम नहीं कर सकता. इन मामलों में, java.net.preferIPv6Addresses=true सिस्टम प्रॉपर्टी का इस्तेमाल करके, बैजेल के काम करने के तरीके को बदला जा सकता है और आईपीवी6 को प्राथमिकता दी जा सकती है.
खास तौर पर:
--host_jvm_args=-Djava.net.preferIPv6Addresses=trueस्टार्टअप विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपनी.bazelrcफ़ाइल में यह लाइन जोड़ें:startup --host_jvm_args=-Djava.net.preferIPv6Addresses=trueइंटरनेट से कनेक्ट करने की ज़रूरत वाले Java बिल्ड टारगेट (जैसे कि इंटिग्रेशन टेस्ट के लिए) चलाते समय,
--jvmopt=-Djava.net.preferIPv6Addresses=trueटूल फ़्लैग का इस्तेमाल करें. उदाहरण के लिए, अपनी.bazelrcफ़ाइल में यह जानकारी शामिल करें:build --jvmopt=-Djava.net.preferIPv6Addressesअगर डिपेंडेंसी वर्शन रिज़ॉल्यूशन के लिए
rules_jvm_externalका इस्तेमाल किया जा रहा है, तोCOURSIER_OPTSएनवायरमेंट वैरिएबल में-Djava.net.preferIPv6Addresses=trueको भी जोड़ें, ताकि Coursier के लिए JVM विकल्प उपलब्ध कराया जा सके.
ऑफ़लाइन बिल्ड
कभी-कभी हो सकता है कि आप बिल्ड को ऑफ़लाइन चलाना चाहें, जैसे कि हवाई जहाज़ से यात्रा करते समय. ऐसे आसान इस्तेमाल के लिए, डेटा स्टोर करने की ज़रूरी जगहों को bazel fetch या bazel sync की मदद से प्रीफ़ेच करें. बिल्ड के दौरान और डेटा स्टोर करने की जगहों को फ़ेच करने की सुविधा बंद करने के लिए, --nofetch विकल्प का इस्तेमाल करें.
सही ऑफ़लाइन बिल्ड के लिए, जहां एक दूसरी इकाई सभी ज़रूरी फ़ाइलें उपलब्ध कराती है, वहां
Bazu, --distdir विकल्प के साथ काम करता है. जब कोई डेटा स्टोर करने की जगह का नियम बेज़ल को ctx.download या ctx.download_and_extract वाली फ़ाइल फ़ेच करने के लिए कहता है, तब यह फ़्लैग बेज़ल को उस विकल्प से तय की गई डायरेक्ट्री में ही जांच करने के लिए कहता है. ज़रूरी फ़ाइल का हैश योग देकर, Baze पहले यूआरएल के बेसनाम से मेल खाने वाली फ़ाइल खोजता है और हैश के मेल खाने पर लोकल कॉपी का इस्तेमाल करता है.
Baज़ल, इस तकनीक का इस्तेमाल करके डिस्ट्रिब्यूशन आर्टफ़ैक्ट से ऑफ़लाइन बूटस्ट्रैप करते हैं.
ऐसा करने के लिए, यह इंटरनल distdir_tar में ज़रूरी बाहरी डिपेंडेंसी का डेटा इकट्ठा करता है.
Baज़ल, रिपॉज़िटरी नियमों में आर्बिट्रेरी कमांड को लागू करने की अनुमति देता है, बिना यह जाने कि क्या वे नेटवर्क से संपर्क करते है. इसलिए, वे पूरी तरह से ऑफ़लाइन बिल्ड लागू नहीं कर सकते. यह जांचने के लिए कि कोई बिल्ड सही तरीके से ऑफ़लाइन काम कर रहा है या नहीं, मैन्युअल रूप से नेटवर्क को ब्लॉक कर दें (जैसा कि Baze अपने बूटस्ट्रैप टेस्ट में करता है).