वर्कस्पेस में डिपेंडेंसी को शैडो करना
जब भी हो सके, अपने प्रोजेक्ट में एक वर्शन नीति का इस्तेमाल करें. यह उन डिपेंडेंसी के लिए ज़रूरी है जिन्हें आप इकट्ठा करते हैं और अपनी फ़ाइनल बाइनरी में ले जाते हैं. अन्य मामलों में, डिपेंडेंसी को शैडो किया जा सकता है:
myproject/WORKSPACE
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 = "...",
)
B/WORKSPACE
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रिपॉज़िटरी को किसी ऐसी स्थानीय डायरेक्ट्री से बदलना जहां बदलाव आसानी से किए जा सकते हैं. - वेंडरिंग. अगर आप किसी ऐसे माहौल में हैं जहां नेटवर्क कॉल नहीं किए जा सकते, तो नेटवर्क पर आधारित रिपॉज़िटरी के नियमों को बदलकर, लोकल डायरेक्ट्री पर जाएं.
प्रॉक्सी का इस्तेमाल करना
Bazel, HTTPS_PROXY और HTTP_PROXY एनवायरमेंट वैरिएबल से प्रॉक्सी पते लेता है और इनका इस्तेमाल HTTP और HTTPS फ़ाइलों को डाउनलोड करने के लिए करता है (अगर तय किया गया हो).
IPv6 के साथ काम करना
सिर्फ़ IPv6 वाली मशीनों पर, Bazel बिना किसी बदलाव के डिपेंडेंसी डाउनलोड कर सकता है. हालांकि, ड्यूअल-स्टैक IPv4/IPv6 मशीनों पर, Bazel उसी तरह के समझौते का पालन करता है जिस तरह Java करता है. अगर IPv4 चालू है, तो Bazel उसे प्राथमिकता देता है. कुछ मामलों में, जैसे कि जब IPv4 नेटवर्क, बाहरी पतों को हल नहीं कर पाता/उन तक नहीं पहुंच पाता, तो Network
unreachable अपवाद और बिल्ड फ़ेल हो सकते हैं. इन मामलों में, java.net.preferIPv6Addresses=true सिस्टम प्रॉपर्टी का इस्तेमाल करके, IPv6 को प्राथमिकता देने के लिए, Bazel के व्यवहार को बदला जा सकता है.
खास तौर पर:
--host_jvm_args=-Djava.net.preferIPv6Addresses=trueस्टार्टअप विकल्प का इस्तेमाल करें. उदाहरण के लिए, अपनी.bazelrcफ़ाइल में यह लाइन जोड़ें:startup --host_jvm_args=-Djava.net.preferIPv6Addresses=trueइंटरनेट से कनेक्ट करने वाले जावा बिल्ड टारगेट (जैसे, इंटिग्रेशन टेस्ट के लिए) को चलाते समय,
--jvmopt=-Djava.net.preferIPv6Addresses=trueटूल के लिए दिए गए फ़्लैग का इस्तेमाल करें. उदाहरण के लिए, अपनी.bazelrcफ़ाइल में ये शामिल करें:build --jvmopt=-Djava.net.preferIPv6Addressesअगर डिपेंडेंसी वर्शन को हल करने के लिए
rules_jvm_externalका इस्तेमाल किया जा रहा है, तो Coursier के लिए JVM के विकल्प देने के लिए,COURSIER_OPTSएनवायरमेंट वैरिएबल में-Djava.net.preferIPv6Addresses=trueभी जोड़ें.
ऑफ़लाइन बिल्ड
कभी-कभी आपको ऑफ़लाइन भी बिल्ड चलाना पड़ सकता है. जैसे, हवाई जहाज़ से यात्रा करते समय. इस्तेमाल के ऐसे आसान उदाहरणों के लिए, ज़रूरी डेटा स्टोर करने की जगहों को पहले से लोड करने के लिए, bazel fetch या bazel sync का इस्तेमाल करें. बिल्ड के दौरान, ज़्यादा रिपॉज़िटरी फ़ेच करने की सुविधा बंद करने के लिए, --nofetch विकल्प का इस्तेमाल करें.
असल ऑफ़लाइन बिल्ड के लिए, जहां कोई दूसरी इकाई सभी ज़रूरी फ़ाइलें उपलब्ध कराती है, तो Bazel में --distdir विकल्प काम करता है. यह फ़्लैग, Bazel को उस विकल्प से तय की गई डायरेक्ट्री में सबसे पहले देखने के लिए कहता है. ऐसा तब होता है, जब कोई रिपॉज़िटरी नियम, Bazel से ctx.download या ctx.download_and_extract वाली फ़ाइल फ़ेच करने के लिए कहता है. ज़रूरी फ़ाइल का हैश जोड़कर, Bazel पहले यूआरएल के बेसनेम से मैच होने वाली फ़ाइल खोजता है. अगर हैश मैच होता है, तो वह लोकल कॉपी का इस्तेमाल करता है.
Bazel खुद इस तकनीक का इस्तेमाल करके, डिस्ट्रिब्यूशन आर्टफ़ैक्ट से ऑफ़लाइन बूटस्ट्रैप करता है.
यह ऐसा, distdir_tar में ज़रूरी सभी बाहरी डिपेंडेंसी इकट्ठा करके करता है.
Bazel, रिपॉज़िटरी के नियमों में मनमुताबिक निर्देशों को लागू करने की अनुमति देता है. ऐसा करने से, यह पता नहीं चलता कि वे नेटवर्क पर कॉल करते हैं या नहीं. इसलिए, पूरी तरह से ऑफ़लाइन बिल्ड लागू नहीं किए जा सकते. यह जांचने के लिए कि कोई बिल्ड ऑफ़लाइन सही तरीके से काम करता है या नहीं, नेटवर्क को मैन्युअल तरीके से ब्लॉक करें. जैसे, Bazel अपने बूटस्ट्रैप जांच में करता है.