रिलीज़ होने वाले किसी भी वर्शन की जानकारी देने वाले दस्तावेज़ के लिए, कृपया "वर्शन दस्तावेज़" ड्रॉप-डाउन का इस्तेमाल करें. डिफ़ॉल्ट व्यू, head पर सबसे नए वर्शन को दिखाता है.

इस पेज का अनुवाद Cloud Translation API से किया गया है.

बाहरी डिपेंडेंसी के बेहतर विषय

समस्या की शिकायत करें सोर्स देखें

वर्कस्पेस में डिपेंडेंसी शैडो किया जा रहा है

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

मेरा प्रोजेक्ट/वर्कस्पेस

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 रिपॉज़िटरी को किसी लोकल डायरेक्ट्री में बदलने के लिए, जहां बदलाव किए जा सकते हैं.
वेंडर बनाना. अगर आप किसी ऐसे माहौल में हैं जहां नेटवर्क कॉल नहीं किए जा सकते, तो नेटवर्क पर आधारित रिपॉज़िटरी के नियमों को बदलें और स्थानीय डायरेक्ट्री पर ले जाएं.

प्रॉक्सी का इस्तेमाल करना

Bazel, HTTPS_PROXY और HTTP_PROXY एनवायरमेंट वैरिएबल से प्रॉक्सी पते चुनता है. साथ ही, इन वैरिएबल का इस्तेमाल करके, HTTP और HTTPS फ़ाइलों (अगर तय किया गया हो) को डाउनलोड करता है.

आईपीवी6 के साथ काम करता है

सिर्फ़ IPv6 डिवाइसों पर, Bazel बिना किसी बदलाव के डिपेंडेंसी डाउनलोड कर सकता है. हालांकि, ड्यूअल-स्टैक IPv4/IPv6 मशीन पर, Bazel 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 भी जोड़ें. इससे Corsier के लिए JVM के विकल्प दिए जा सकेंगे.

ऑफ़लाइन बिल्ड

कभी-कभी हो सकता है कि आप बिल्ड ऑफ़लाइन चलाना चाहें, जैसे कि हवाई जहाज़ में यात्रा करते समय. इस्तेमाल के ऐसे आसान उदाहरणों के लिए, ज़रूरी डेटा स्टोर करने की जगहों को bazel fetch या bazel sync से प्रीफ़ेच करें. बिल्ड के दौरान रिपॉज़िटरी को फ़ेच करने की सुविधा बंद करने के लिए, --nofetch विकल्प का इस्तेमाल करें.

सही ऑफ़लाइन बिल्ड के लिए, जहां एक अलग इकाई सभी ज़रूरी फ़ाइलों की सप्लाई करती है, वहां Bazel --distdir विकल्प के साथ काम करता है. जब कोई रिपॉज़िटरी नियम, Bazel को ctx.download या ctx.download_and_extract के साथ कोई फ़ाइल फ़ेच करने के लिए कहता है, तो यह फ़्लैग Bazel को उस विकल्प के ज़रिए बताई गई डायरेक्ट्री में देखने के लिए कहता है. ज़रूरी फ़ाइल का हैश योग देकर, Bazel पहले यूआरएल के आधार नाम से मेल खाने वाली फ़ाइल खोजता है. अगर हैश मैच होता है, तो लोकल कॉपी का इस्तेमाल करता है.

Bazel खुद डिस्ट्रिब्यूशन आर्टफ़ैक्ट से ऑफ़लाइन बूटस्ट्रैप करने के लिए इस तकनीक का इस्तेमाल करता है. ऐसा करने के लिए, सभी ज़रूरी बाहरी डिपेंडेंसी संगठन के distdir_tar टूल में इकट्ठा किए जाते हैं.

Bazel, रिपॉज़िटरी के नियमों में, आर्बिट्रेरी कमांड चलाने की अनुमति देता है. हालांकि, इससे यह पता नहीं चलता कि वे नेटवर्क को कॉल कर रहे हैं या नहीं. इस वजह से, पूरी तरह से ऑफ़लाइन बिल्ड लागू नहीं किए जा सकते. यह जांचने के लिए कि क्या कोई बिल्ड ठीक से ऑफ़लाइन काम करता है, मैन्युअल रूप से नेटवर्क को ब्लॉक करें (जैसा कि Bazel अपने बूटस्ट्रैप टेस्ट में करता है).