एचटीटीपी रिपॉज़िटरी के नियम

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

इन फ़ंक्शन को @bazel_tools//tools/build_defs/repo:http.bzl से लोड किया जा सकता है.

एचटीटीपी पर फ़ाइलें और संग्रह डाउनलोड करने के नियम.

सेटअप

मॉड्यूल एक्सटेंशन में इन नियमों का इस्तेमाल करने के लिए, उन्हें अपनी .bzl फ़ाइल में लोड करें. इसके बाद, उन्हें अपने एक्सटेंशन के लागू करने वाले फ़ंक्शन से कॉल करें. उदाहरण के लिए, http_archive का इस्तेमाल करने के लिए:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

def _my_extension_impl(mctx):
  http_archive(name = "foo", urls = [...])

my_extension = module_extension(implementation = _my_extension_impl)

इसके अलावा, use_repo_rule की मदद से, MODULE.bazel फ़ाइल में इन रेपो नियमों को सीधे तौर पर कॉल किया जा सकता है:

http_archive = use_repo_rule("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(name = "foo", urls = [...])

http_archive

http_archive(name, add_prefix, auth_patterns, build_file, build_file_content, canonical_id,
             integrity, netrc, patch_args, patch_cmds, patch_cmds_win, patch_tool, patches,
             remote_file_integrity, remote_file_urls, remote_patch_strip, remote_patches,
             repo_mapping, sha256, strip_prefix, type, url, urls, workspace_file,
             workspace_file_content)

यह Bazel रिपॉज़िटरी को कंप्रेस की गई संग्रह फ़ाइल के तौर पर डाउनलोड करता है, उसे डीकंप्रेस करता है, और उसके टारगेट को बाइंड करने के लिए उपलब्ध कराता है.

यह इन फ़ाइल एक्सटेंशन के साथ काम करता है: "zip", "jar", "war", "aar", "tar", "tar.gz", "tgz", "tar.xz", "txz", "tar.zst", "tzst", tar.bz2, "ar", या "deb".

उदाहरण: मान लें कि मौजूदा रिपॉज़िटरी में, चैट प्रोग्राम का सोर्स कोड मौजूद है. यह कोड, ~/chat-app डायरेक्ट्री में सेव है. इसे किसी ऐसी एसएसएल लाइब्रेरी पर निर्भर होना चाहिए जो http://example.com/openssl.zip पर उपलब्ध है. इस .zip फ़ाइल में, डायरेक्ट्री का यह स्ट्रक्चर शामिल है:

  WORKSPACE
  src/
    openssl.cc
    openssl.h

स्थानीय रिपॉज़िटरी में, उपयोगकर्ता एक openssl.BUILD फ़ाइल बनाता है. इसमें टारगेट की यह परिभाषा शामिल होती है:

  cc_library(
      name = "openssl-lib",
      srcs = ["src/openssl.cc"],
      hdrs = ["src/openssl.h"],
  )

अगर ~/chat-app/WORKSPACE में ये लाइनें जोड़ी जाती हैं, तो ~/chat-app रिपॉज़िटरी में मौजूद टारगेट, इस टारगेट पर निर्भर हो सकते हैं:

  load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

  http_archive(
      name = "my_ssl",
      url = "http://example.com/openssl.zip",
      sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
      build_file = "@//:openssl.BUILD",
  )

इसके बाद, टारगेट @my_ssl//:openssl-lib को डिपेंडेंसी के तौर पर तय करेंगे.

विशेषताएं

name नाम; ज़रूरी है

इस रिपॉज़िटरी के लिए यूनीक नाम.

add_prefix स्ट्रिंग; ज़रूरी नहीं

रिपॉज़िटरी डायरेक्ट्री के हिसाब से डेस्टिनेशन डायरेक्ट्री. संग्रहित की गई फ़ाइल को इस डायरेक्ट्री में अनपैक किया जाएगा. इसके लिए, संग्रह में मौजूद फ़ाइल पाथ पर `strip_prefix` लागू किया जाएगा. उदाहरण के लिए, अगर `add_prefix = "bar"` और `strip_prefix = "foo-1.2.3"` है, तो `foo-1.2.3/src/foo.h` फ़ाइल को `bar/src/foo.h` में अनपैक किया जाएगा.

auth_patterns डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी नहीं

यह एक डिक्शनरी है, जिसमें होस्टनेम को कस्टम ऑथराइज़ेशन पैटर्न से मैप किया जाता है. हालांकि, ऐसा करना ज़रूरी नहीं है. अगर किसी यूआरएल का होस्टनेम इस डिक्शनरी में मौजूद है, तो वैल्यू का इस्तेमाल पैटर्न के तौर पर किया जाएगा. ऐसा एचटीटीपी अनुरोध के लिए अनुमति देने वाला हेडर जनरेट करते समय किया जाएगा. इससे, क्लाउड स्टोरेज की सेवाएं देने वाली कई कंपनियों के कस्टम ऑथराइज़ेशन स्कीम का इस्तेमाल किया जा सकता है. फ़िलहाल, पैटर्न में दो टोकन इस्तेमाल किए जा सकते हैं: <login> और <password>. इन्हें एक ही होस्ट नेम के लिए, netrc फ़ाइल में मौजूद इनकी वैल्यू से बदल दिया जाता है. फ़ॉर्मैट करने के बाद, नतीजे को एचटीटीपी अनुरोध के Authorization फ़ील्ड की वैल्यू के तौर पर सेट किया जाता है. बेयरर टोकन का इस्तेमाल करके, OAuth2 की सुविधा वाले एपीआई से एचटीटीपी डाउनलोड करने के लिए, एट्रिब्यूट और netrc का उदाहरण: 

auth_patterns = {
    "storage.cloudprovider.com": "Bearer <password>"
}
netrc: 
machine storage.cloudprovider.com
        password RANDOM-TOKEN
फ़ाइनल एचटीटीपी अनुरोध में यह हेडर होगा: 
Authorization: Bearer RANDOM-TOKEN

build_file लेबल; ज़रूरी नहीं है

इस रिपॉज़िटरी के लिए, BUILD फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. यह एट्रिब्यूट, ऐब्सलूट लेबल है. मुख्य रिपॉज़िटरी के लिए '@//' का इस्तेमाल करें. यह ज़रूरी नहीं है कि फ़ाइल का नाम BUILD हो. हालांकि, ऐसा किया जा सकता है. जैसे, BUILD.new-repo-name नाम रखने से, इसे रिपॉज़िटरी की असल BUILD फ़ाइलों से अलग करने में मदद मिल सकती है. build_file या build_file_content में से किसी एक को तय किया जा सकता है, लेकिन दोनों को नहीं.

build_file_content स्ट्रिंग; ज़रूरी नहीं

इस रिपॉज़िटरी के लिए BUILD फ़ाइल का कॉन्टेंट. build_file या build_file_content में से किसी एक को तय किया जा सकता है, लेकिन दोनों को नहीं.

canonical_id स्ट्रिंग; ज़रूरी नहीं

डाउनलोड की गई फ़ाइल का कैननिकल आईडी. अगर इसे तय किया गया है और यह खाली नहीं है, तो Bazel फ़ाइल को कैश मेमोरी से नहीं लेगा. ऐसा तब तक होगा, जब तक इसे एक ही कैननिकल आईडी वाले अनुरोध से कैश मेमोरी में न जोड़ा गया हो. अगर यह जानकारी नहीं दी गई है या खाली है, तो Bazel डिफ़ॉल्ट रूप से फ़ाइल के यूआरएल को कैननिकल आईडी के तौर पर इस्तेमाल करता है. इससे, यूआरएल को अपडेट करने के दौरान होने वाली आम गलती को ठीक करने में मदद मिलती है. यह गलती तब होती है, जब यूआरएल के साथ हैश को अपडेट नहीं किया जाता. इससे, लोकल मशीन पर तो बिल्ड बन जाते हैं, लेकिन उन मशीनों पर नहीं बन पाते जिनमें कैश मेमोरी में फ़ाइल मौजूद नहीं होती. इस सुविधा को बंद करने के लिए, --repo_env=BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID=0 का इस्तेमाल करें.

integrity स्ट्रिंग; ज़रूरी नहीं

डाउनलोड की गई फ़ाइल का, सबरिसॉर्स इंटिग्रिटी फ़ॉर्मैट में अनुमानित चेकसम. यह डाउनलोड की गई फ़ाइल के चेकसम से मेल खाना चाहिए. _चेकसाम को शामिल न करने से सुरक्षा से जुड़ा जोखिम हो सकता है, क्योंकि रिमोट फ़ाइलों में बदलाव किया जा सकता है._ इस फ़ील्ड को शामिल न करने पर, आपका बिल्ड नॉन-हर्मेटिक हो जाएगा. इससे डेवलपमेंट को आसान बनाने में मदद मिलती है. हालांकि, शिपिंग से पहले इस एट्रिब्यूट या `sha256` में से किसी एक को सेट करना ज़रूरी है.

netrc स्ट्रिंग; ज़रूरी नहीं

पुष्टि के लिए इस्तेमाल की जाने वाली .netrc फ़ाइल की जगह

patch_args स्ट्रिंग की सूची; ज़रूरी नहीं

पैच टूल को दिए गए तर्क. डिफ़ॉल्ट रूप से -p0 पर सेट होता है. हालांकि, git से जनरेट किए गए पैच के लिए आम तौर पर -p1 की ज़रूरत होती है. अगर कई -p आर्ग्युमेंट दिए गए हैं, तो आखिरी आर्ग्युमेंट लागू होगा.अगर -p के अलावा अन्य आर्ग्युमेंट दिए गए हैं, तो Bazel, Bazel-नेटिव पैच लागू करने के बजाय, पैच कमांड लाइन टूल का इस्तेमाल करेगा. जब पैच कमांड लाइन टूल पर वापस आ रहे हों और patch_tool एट्रिब्यूट की वैल्यू नहीं दी गई हो, तब `patch` का इस्तेमाल किया जाएगा. इससे सिर्फ़ `patches` एट्रिब्यूट में मौजूद पैच फ़ाइलों पर असर पड़ता है.

patch_cmds स्ट्रिंग की सूची; ज़रूरी नहीं

पैच लागू होने के बाद, Linux/Macos पर लागू की जाने वाली Bash कमांड का क्रम.

patch_cmds_win स्ट्रिंग की सूची; ज़रूरी नहीं

पैच लागू होने के बाद, Windows पर लागू की जाने वाली Powershell कमांड का क्रम. अगर इस एट्रिब्यूट को सेट नहीं किया जाता है, तो Windows पर patch_cmds को एक्ज़ीक्यूट किया जाएगा. इसके लिए, Bash बाइनरी का मौजूद होना ज़रूरी है.

patch_tool स्ट्रिंग; ज़रूरी नहीं

इस्तेमाल की जाने वाली patch(1) यूटिलिटी. अगर इसे तय किया जाता है, तो Bazel, Bazel के नेटिव पैच लागू करने के बजाय, तय किए गए पैच टूल का इस्तेमाल करेगा.

patches लेबल की सूची; यह विकल्प इस्तेमाल करना ज़रूरी नहीं है

यह उन फ़ाइलों की सूची है जिन्हें संग्रह को निकालने के बाद पैच के तौर पर लागू किया जाना है. डिफ़ॉल्ट रूप से, यह Bazel-native पैच लागू करने की सुविधा का इस्तेमाल करता है. यह सुविधा, फ़ज़ मैच और बाइनरी पैच के साथ काम नहीं करती. हालांकि, अगर `patch_tool` एट्रिब्यूट की वैल्यू दी गई है या `patch_args` एट्रिब्यूट में `-p` के अलावा अन्य आर्ग्युमेंट मौजूद हैं, तो Bazel, पैच कमांड लाइन टूल का इस्तेमाल करेगा.

remote_file_integrity डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी नहीं

यह फ़ाइल के रिलेटिव पाथ (कुंजी) को उसकी इंटिग्रिटी वैल्यू (वैल्यू) पर मैप करता है. ये रिलेटिव पाथ, `remote_file_urls` एट्रिब्यूट में मौजूद फ़ाइलों (कुंजी) से मैप होने चाहिए.

remote_file_urls डिक्शनरी: स्ट्रिंग -> स्ट्रिंग की सूची; ज़रूरी नहीं

यह रिलेटिव पाथ (कुंजी) के मैप से यूआरएल (वैल्यू) की सूची बनाता है. इन यूआरएल को डाउनलोड किया जाता है और रिपॉज़िटरी में ओवरले की गई फ़ाइलों के तौर पर उपलब्ध कराया जाता है. यह तब काम आता है, जब आपको किसी मौजूदा रिपॉज़िटरी में WORKSPACE या BUILD.bazel फ़ाइलें जोड़नी हों. `patches` एट्रिब्यूट में पैच लागू करने से पहले, फ़ाइलें डाउनलोड की जाती हैं. साथ ही, यूआरएल की सूची में एक ही फ़ाइल के सभी संभावित मिरर होने चाहिए. जब तक कोई यूआरएल काम नहीं करता, तब तक यूआरएल को क्रम से आज़माया जाता है.

remote_patch_strip पूर्णांक; ज़रूरी नहीं

रिमोट पैच में फ़ाइल के नाम से हटाए जाने वाले शुरुआती स्लैश की संख्या.

remote_patches डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी नहीं

यह पैच फ़ाइल के यूआरएल और उसकी इंटिग्रिटी वैल्यू का मैप होता है. इन्हें संग्रह को निकालने के बाद और `patches` एट्रिब्यूट से पैच फ़ाइलें लागू करने से पहले लागू किया जाता है. यह Bazel-नेटिव पैच लागू करने की सुविधा का इस्तेमाल करता है. `remote_patch_strip` की मदद से, पैच स्ट्रिप नंबर तय किया जा सकता है

repo_mapping Dictionary: String -> String; ज़रूरी है

लोकल रिपॉज़िटरी के नाम से ग्लोबल रिपॉज़िटरी के नाम तक की डिक्शनरी. इससे इस रिपॉज़िटरी की डिपेंडेंसी के लिए, वर्कस्पेस डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है.

उदाहरण के लिए, `"@foo": "@bar"` एंट्री से यह पता चलता है कि जब भी यह रिपॉज़िटरी `@foo` पर निर्भर करती है (जैसे कि `@foo//some:target` पर निर्भरता), तो इसे असल में, वैश्विक तौर पर घोषित `@bar` (`@bar//some:target`) के अंदर उस निर्भरता को हल करना चाहिए.

sha256 स्ट्रिंग; ज़रूरी नहीं

डाउनलोड की गई फ़ाइल का SHA-256 हैश. यह, डाउनलोड की गई फ़ाइल के SHA-256 से मेल खाना चाहिए. _SHA-256 को शामिल न करने से सुरक्षा से जुड़ी समस्या हो सकती है, क्योंकि रिमोट फ़ाइलें बदल सकती हैं._ इस फ़ील्ड को शामिल न करने से, आपका बिल्ड हर्मेटिक नहीं रहेगा. इससे डेवलपमेंट को आसान बनाने में मदद मिलती है. हालांकि, शिपिंग से पहले इस एट्रिब्यूट या `integrity` को सेट करना ज़रूरी है.

strip_prefix स्ट्रिंग; ज़रूरी नहीं

यह एक डायरेक्ट्री प्रीफ़िक्स है, जिसे निकाली गई फ़ाइलों से हटाया जाता है. कई संग्रहों में टॉप-लेवल की डायरेक्ट्री होती है. इसमें संग्रह की सभी काम की फ़ाइलें शामिल होती हैं. `build_file` में इस प्रीफ़िक्स को बार-बार तय करने के बजाय, इस फ़ील्ड का इस्तेमाल करके इसे सभी एक्सट्रैक्ट की गई फ़ाइलों से हटाया जा सकता है. उदाहरण के लिए, मान लें कि आपको `foo-lib-latest.zip` का इस्तेमाल करना है. इसमें `foo-lib-1.2.3/` डायरेक्ट्री है. इसके अंदर `WORKSPACE` फ़ाइल है. साथ ही, `src/`, `lib/`, और `test/` डायरेक्ट्री हैं. इनमें वह कोड मौजूद है जिसे आपको बनाना है. टॉप-लेवल की डायरेक्ट्री के तौर पर `foo-lib-1.2.3` डायरेक्ट्री का इस्तेमाल करने के लिए, `strip_prefix = "foo-lib-1.2.3"` तय करें. ध्यान दें कि अगर इस डायरेक्ट्री के बाहर कोई फ़ाइल मौजूद है, तो उसे हटा दिया जाएगा और उसे ऐक्सेस नहीं किया जा सकेगा. उदाहरण के लिए, टॉप-लेवल की लाइसेंस फ़ाइल. इसमें ऐसी फ़ाइलें/डायरेक्ट्री शामिल हैं जिनके नाम प्रीफ़िक्स से शुरू होते हैं, लेकिन वे डायरेक्ट्री में नहीं हैं (उदाहरण के लिए, `foo-lib-1.2.3.release-notes`). अगर दिया गया प्रीफ़िक्स, संग्रह में मौजूद किसी डायरेक्ट्री से मेल नहीं खाता है, तो Bazel गड़बड़ी का मैसेज दिखाएगा.

type स्ट्रिंग; ज़रूरी नहीं

डाउनलोड की गई फ़ाइल का संग्रह टाइप. डिफ़ॉल्ट रूप से, संग्रह के टाइप का पता यूआरएल के फ़ाइल एक्सटेंशन से चलता है. अगर फ़ाइल का कोई एक्सटेंशन नहीं है, तो इनमें से कोई एक एक्सटेंशन साफ़ तौर पर बताया जा सकता है: `"zip"`, `"jar"`, `"war"`, `"aar"`, `"tar"`, `"tar.gz"`, `"tgz"`, `"tar.xz"`, `"txz"`, `"tar.zst"`, `"tzst"`, `"tar.bz2"`, `"ar"` या `"deb"`.

url स्ट्रिंग; ज़रूरी नहीं

उस फ़ाइल का यूआरएल जिसे Bazel के लिए उपलब्ध कराया जाएगा. यह एक फ़ाइल, http या https यूआरएल होना चाहिए. रीडायरेक्ट किए गए यूआरएल को इसमें शामिल किया जाता है. पुष्टि करने की सुविधा काम नहीं करती. urls पैरामीटर की मदद से, ज़्यादा फ़्लेक्सिबिलिटी हासिल की जा सकती है. इसकी मदद से, फ़ेच करने के लिए वैकल्पिक यूआरएल तय किए जा सकते हैं.

urls स्ट्रिंग की सूची; ज़रूरी नहीं

यह एक ऐसी फ़ाइल के यूआरएल की सूची होती है जिसे Bazel के लिए उपलब्ध कराया जाएगा. हर एंट्री एक फ़ाइल, http या https यूआरएल होनी चाहिए. रीडायरेक्ट किए गए यूआरएल को इसमें शामिल किया जाता है. पुष्टि करने की सुविधा काम नहीं करती. जब तक कोई यूआरएल काम नहीं करता, तब तक यूआरएल को क्रम से आज़माया जाता है. इसलिए, आपको सबसे पहले स्थानीय मिरर की सूची बनानी चाहिए. अगर सभी डाउनलोड पूरे नहीं होते हैं, तो नियम लागू नहीं होगा.

workspace_file लेबल; ज़रूरी नहीं है

इस रिपॉज़िटरी के लिए, `WORKSPACE` फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. `workspace_file` या `workspace_file_content` में से किसी एक को तय किया जा सकता है. हालांकि, दोनों को एक साथ तय नहीं किया जा सकता. इसके अलावा, किसी को भी तय न करने का विकल्प भी होता है.

workspace_file_content स्ट्रिंग; ज़रूरी नहीं

इस रिपॉज़िटरी के लिए WORKSPACE फ़ाइल का कॉन्टेंट. `workspace_file` या `workspace_file_content` में से किसी एक को तय किया जा सकता है. हालांकि, दोनों को एक साथ तय नहीं किया जा सकता. इसके अलावा, किसी को भी तय न करने का विकल्प भी होता है.

http_file

http_file(name, auth_patterns, canonical_id, downloaded_file_path, executable, integrity, netrc,
          repo_mapping, sha256, url, urls)

यह फ़ंक्शन, किसी यूआरएल से फ़ाइल डाउनलोड करता है और उसे फ़ाइल ग्रुप के तौर पर इस्तेमाल करने के लिए उपलब्ध कराता है.

उदाहरण: मान लें कि आपको कस्टम नियमों के लिए डेबियन पैकेज की ज़रूरत है. यह पैकेज http://example.com/package.deb पर उपलब्ध है. इसके बाद, अपने WORKSPACE फ़ाइल में ये चीज़ें जोड़ी जा सकती हैं:

  load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")

  http_file(
      name = "my_deb",
      url = "http://example.com/package.deb",
      sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  )

टारगेट, इस फ़ाइल पर निर्भर रहने के लिए @my_deb//file को डिपेंडेंसी के तौर पर तय करेंगे.

विशेषताएं

name नाम; ज़रूरी है

इस रिपॉज़िटरी के लिए यूनीक नाम.

auth_patterns डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी नहीं

यह एक डिक्शनरी है, जिसमें होस्टनेम को कस्टम ऑथराइज़ेशन पैटर्न से मैप किया जाता है. हालांकि, ऐसा करना ज़रूरी नहीं है. अगर किसी यूआरएल का होस्टनेम इस डिक्शनरी में मौजूद है, तो वैल्यू का इस्तेमाल पैटर्न के तौर पर किया जाएगा. ऐसा एचटीटीपी अनुरोध के लिए अनुमति देने वाला हेडर जनरेट करते समय किया जाएगा. इससे, क्लाउड स्टोरेज की सेवाएं देने वाली कई कंपनियों के कस्टम ऑथराइज़ेशन स्कीम का इस्तेमाल किया जा सकता है. फ़िलहाल, पैटर्न में दो टोकन इस्तेमाल किए जा सकते हैं: <login> और <password>. इन्हें एक ही होस्ट नेम के लिए, netrc फ़ाइल में मौजूद इनकी वैल्यू से बदल दिया जाता है. फ़ॉर्मैट करने के बाद, नतीजे को एचटीटीपी अनुरोध के Authorization फ़ील्ड की वैल्यू के तौर पर सेट किया जाता है. बेयरर टोकन का इस्तेमाल करके, OAuth2 की सुविधा वाले एपीआई से एचटीटीपी डाउनलोड करने के लिए, एट्रिब्यूट और netrc का उदाहरण: 

auth_patterns = {
    "storage.cloudprovider.com": "Bearer <password>"
}
netrc: 
machine storage.cloudprovider.com
        password RANDOM-TOKEN
फ़ाइनल एचटीटीपी अनुरोध में यह हेडर होगा: 
Authorization: Bearer RANDOM-TOKEN

canonical_id स्ट्रिंग; ज़रूरी नहीं

डाउनलोड की गई फ़ाइल का कैननिकल आईडी. अगर इसे तय किया गया है और यह खाली नहीं है, तो Bazel फ़ाइल को कैश मेमोरी से नहीं लेगा. ऐसा तब तक होगा, जब तक इसे एक ही कैननिकल आईडी वाले अनुरोध से कैश मेमोरी में न जोड़ा गया हो. अगर यह जानकारी नहीं दी गई है या खाली है, तो Bazel डिफ़ॉल्ट रूप से फ़ाइल के यूआरएल को कैननिकल आईडी के तौर पर इस्तेमाल करता है. इससे, यूआरएल को अपडेट करने के दौरान होने वाली आम गलती को ठीक करने में मदद मिलती है. यह गलती तब होती है, जब यूआरएल के साथ हैश को अपडेट नहीं किया जाता. इससे, लोकल मशीन पर तो बिल्ड बन जाते हैं, लेकिन उन मशीनों पर नहीं बन पाते जिनमें कैश मेमोरी में फ़ाइल मौजूद नहीं होती. इस सुविधा को बंद करने के लिए, --repo_env=BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID=0 का इस्तेमाल करें.

downloaded_file_path स्ट्रिंग; ज़रूरी नहीं

डाउनलोड की गई फ़ाइल को असाइन किया गया पाथ

executable बूलियन; ज़रूरी नहीं

अगर डाउनलोड की गई फ़ाइल को एक्ज़ीक्यूटेबल बनाया जाना चाहिए.

integrity स्ट्रिंग; ज़रूरी नहीं

डाउनलोड की गई फ़ाइल का, सबरिसॉर्स इंटिग्रिटी फ़ॉर्मैट में अनुमानित चेकसम. यह डाउनलोड की गई फ़ाइल के चेकसम से मेल खाना चाहिए. _चेकसाम को शामिल न करने से सुरक्षा से जुड़ा जोखिम हो सकता है, क्योंकि रिमोट फ़ाइलों में बदलाव किया जा सकता है._ इस फ़ील्ड को शामिल न करने पर, आपका बिल्ड नॉन-हर्मेटिक हो जाएगा. इससे डेवलपमेंट को आसान बनाने में मदद मिलती है. हालांकि, शिपिंग से पहले इस एट्रिब्यूट या `sha256` में से किसी एक को सेट करना ज़रूरी है.

netrc स्ट्रिंग; ज़रूरी नहीं

पुष्टि के लिए इस्तेमाल की जाने वाली .netrc फ़ाइल की जगह

repo_mapping Dictionary: String -> String; ज़रूरी है

लोकल रिपॉज़िटरी के नाम से ग्लोबल रिपॉज़िटरी के नाम तक की डिक्शनरी. इससे इस रिपॉज़िटरी की डिपेंडेंसी के लिए, वर्कस्पेस डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है.

उदाहरण के लिए, `"@foo": "@bar"` एंट्री से यह पता चलता है कि जब भी यह रिपॉज़िटरी `@foo` पर निर्भर करती है (जैसे कि `@foo//some:target` पर निर्भरता), तो इसे असल में, वैश्विक तौर पर घोषित `@bar` (`@bar//some:target`) के अंदर उस निर्भरता को हल करना चाहिए.

sha256 स्ट्रिंग; ज़रूरी नहीं

डाउनलोड की गई फ़ाइल का SHA-256 हैश. यह, डाउनलोड की गई फ़ाइल के SHA-256 से मेल खाना चाहिए. _SHA-256 को शामिल न करने से सुरक्षा से जुड़ी समस्या हो सकती है, क्योंकि रिमोट फ़ाइलें बदल सकती हैं._ इस फ़ील्ड को शामिल न करने से, आपका बिल्ड हर्मेटिक नहीं रहेगा. इससे डेवलपमेंट को आसान बनाने में मदद मिलती है. हालांकि, इसे शिपिंग से पहले सेट करना ज़रूरी है.

url स्ट्रिंग; ज़रूरी नहीं

उस फ़ाइल का यूआरएल जिसे Bazel के लिए उपलब्ध कराया जाएगा. यह एक फ़ाइल, http या https यूआरएल होना चाहिए. रीडायरेक्ट किए गए यूआरएल को इसमें शामिल किया जाता है. पुष्टि करने की सुविधा काम नहीं करती. urls पैरामीटर की मदद से, ज़्यादा फ़्लेक्सिबिलिटी हासिल की जा सकती है. इसकी मदद से, फ़ेच करने के लिए वैकल्पिक यूआरएल तय किए जा सकते हैं.

urls स्ट्रिंग की सूची; ज़रूरी नहीं

यह एक ऐसी फ़ाइल के यूआरएल की सूची होती है जिसे Bazel के लिए उपलब्ध कराया जाएगा. हर एंट्री एक फ़ाइल, http या https यूआरएल होनी चाहिए. रीडायरेक्ट किए गए यूआरएल को इसमें शामिल किया जाता है. पुष्टि करने की सुविधा काम नहीं करती. जब तक कोई यूआरएल काम नहीं करता, तब तक यूआरएल को क्रम से आज़माया जाता है. इसलिए, आपको सबसे पहले स्थानीय मिरर की सूची बनानी चाहिए. अगर सभी डाउनलोड पूरे नहीं होते हैं, तो नियम लागू नहीं होगा.

http_jar

http_jar(name, auth_patterns, canonical_id, downloaded_file_name, integrity, netrc, repo_mapping,
         sha256, url, urls)

यह किसी यूआरएल से जार डाउनलोड करता है और उसे java_import के तौर पर उपलब्ध कराता है

डाउनलोड की गई फ़ाइलों में .jar एक्सटेंशन होना चाहिए.

उदाहरण: मान लें कि मौजूदा रिपॉज़िटरी में, चैट प्रोग्राम का सोर्स कोड है. यह ~/chat-app डायरेक्ट्री में मौजूद है. यह http://example.com/openssl-0.2.jar से उपलब्ध एसएसएल लाइब्रेरी पर निर्भर होना चाहिए.

अगर ~/chat-app/WORKSPACE में ये लाइनें जोड़ी जाती हैं, तो ~/chat-app रिपॉज़िटरी में मौजूद टारगेट, इस टारगेट पर निर्भर हो सकते हैं:

  load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_jar")

  http_jar(
      name = "my_ssl",
      url = "http://example.com/openssl-0.2.jar",
      sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
  )

टारगेट, इस जार पर निर्भर रहने के लिए @my_ssl//jar को डिपेंडेंसी के तौर पर तय करेंगे.

अगर Unix पर काम करने वाले सिस्टम का इस्तेमाल किया जा रहा है, तो "file:///path/to/file" का इस्तेमाल करके, मौजूदा सिस्टम (लोकलहोस्ट) पर मौजूद फ़ाइलों को भी रेफ़रंस के तौर पर इस्तेमाल किया जा सकता है. अगर Windows का इस्तेमाल किया जा रहा है, तो "file:///c:/path/to/file" का इस्तेमाल करें. दोनों उदाहरणों में, तीन स्लैश (/) पर ध्यान दें. पहले दो स्लैश file:// से जुड़े हैं और तीसरा स्लैश, फ़ाइल के ऐब्सलूट पाथ से जुड़ा है.

विशेषताएं

name नाम; ज़रूरी है

इस रिपॉज़िटरी के लिए यूनीक नाम.

auth_patterns डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी नहीं

यह एक डिक्शनरी है, जिसमें होस्टनेम को कस्टम ऑथराइज़ेशन पैटर्न से मैप किया जाता है. हालांकि, ऐसा करना ज़रूरी नहीं है. अगर किसी यूआरएल का होस्टनेम इस डिक्शनरी में मौजूद है, तो वैल्यू का इस्तेमाल पैटर्न के तौर पर किया जाएगा. ऐसा एचटीटीपी अनुरोध के लिए अनुमति देने वाला हेडर जनरेट करते समय किया जाएगा. इससे, क्लाउड स्टोरेज की सेवाएं देने वाली कई कंपनियों के कस्टम ऑथराइज़ेशन स्कीम का इस्तेमाल किया जा सकता है. फ़िलहाल, पैटर्न में दो टोकन इस्तेमाल किए जा सकते हैं: <login> और <password>. इन्हें एक ही होस्ट नेम के लिए, netrc फ़ाइल में मौजूद इनकी वैल्यू से बदल दिया जाता है. फ़ॉर्मैट करने के बाद, नतीजे को एचटीटीपी अनुरोध के Authorization फ़ील्ड की वैल्यू के तौर पर सेट किया जाता है. बेयरर टोकन का इस्तेमाल करके, OAuth2 की सुविधा वाले एपीआई से एचटीटीपी डाउनलोड करने के लिए, एट्रिब्यूट और netrc का उदाहरण: 

auth_patterns = {
    "storage.cloudprovider.com": "Bearer <password>"
}
netrc: 
machine storage.cloudprovider.com
        password RANDOM-TOKEN
फ़ाइनल एचटीटीपी अनुरोध में यह हेडर होगा: 
Authorization: Bearer RANDOM-TOKEN

canonical_id स्ट्रिंग; ज़रूरी नहीं

डाउनलोड की गई फ़ाइल का कैननिकल आईडी. अगर इसे तय किया गया है और यह खाली नहीं है, तो Bazel फ़ाइल को कैश मेमोरी से नहीं लेगा. ऐसा तब तक होगा, जब तक इसे एक ही कैननिकल आईडी वाले अनुरोध से कैश मेमोरी में न जोड़ा गया हो. अगर यह जानकारी नहीं दी गई है या खाली है, तो Bazel डिफ़ॉल्ट रूप से फ़ाइल के यूआरएल को कैननिकल आईडी के तौर पर इस्तेमाल करता है. इससे, यूआरएल को अपडेट करने के दौरान होने वाली आम गलती को ठीक करने में मदद मिलती है. यह गलती तब होती है, जब यूआरएल के साथ हैश को अपडेट नहीं किया जाता. इससे, लोकल मशीन पर तो बिल्ड बन जाते हैं, लेकिन उन मशीनों पर नहीं बन पाते जिनमें कैश मेमोरी में फ़ाइल मौजूद नहीं होती. इस सुविधा को बंद करने के लिए, --repo_env=BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID=0 का इस्तेमाल करें.

downloaded_file_name स्ट्रिंग; ज़रूरी नहीं

डाउनलोड किए गए जार को असाइन किया गया फ़ाइल का नाम

integrity स्ट्रिंग; ज़रूरी नहीं

डाउनलोड की गई फ़ाइल का, सबरिसॉर्स इंटिग्रिटी फ़ॉर्मैट में अनुमानित चेकसम. यह डाउनलोड की गई फ़ाइल के चेकसम से मेल खाना चाहिए. _चेकसाम को शामिल न करने से सुरक्षा से जुड़ा जोखिम हो सकता है, क्योंकि रिमोट फ़ाइलों में बदलाव किया जा सकता है._ इस फ़ील्ड को शामिल न करने पर, आपका बिल्ड नॉन-हर्मेटिक हो जाएगा. इससे डेवलपमेंट को आसान बनाने में मदद मिलती है. हालांकि, शिपिंग से पहले इस एट्रिब्यूट या `sha256` में से किसी एक को सेट करना ज़रूरी है.

netrc स्ट्रिंग; ज़रूरी नहीं

पुष्टि के लिए इस्तेमाल की जाने वाली .netrc फ़ाइल की जगह

repo_mapping Dictionary: String -> String; ज़रूरी है

लोकल रिपॉज़िटरी के नाम से ग्लोबल रिपॉज़िटरी के नाम तक की डिक्शनरी. इससे इस रिपॉज़िटरी की डिपेंडेंसी के लिए, वर्कस्पेस डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है.

उदाहरण के लिए, `"@foo": "@bar"` एंट्री से यह पता चलता है कि जब भी यह रिपॉज़िटरी `@foo` पर निर्भर करती है (जैसे कि `@foo//some:target` पर निर्भरता), तो इसे असल में, वैश्विक तौर पर घोषित `@bar` (`@bar//some:target`) के अंदर उस निर्भरता को हल करना चाहिए.

sha256 स्ट्रिंग; ज़रूरी नहीं

डाउनलोड की गई फ़ाइल का SHA-256 हैश. यह, डाउनलोड की गई फ़ाइल के SHA-256 से मेल खाना चाहिए. _SHA-256 को शामिल न करने से सुरक्षा से जुड़ी समस्या हो सकती है, क्योंकि रिमोट फ़ाइलें बदल सकती हैं._ इस फ़ील्ड को शामिल न करने से, आपका बिल्ड हर्मेटिक नहीं रहेगा. इससे डेवलपमेंट को आसान बनाने में मदद मिलती है. हालांकि, शिपिंग से पहले इस एट्रिब्यूट या `integrity` को सेट करना ज़रूरी है.

url स्ट्रिंग; ज़रूरी नहीं

उस फ़ाइल का यूआरएल जिसे Bazel के लिए उपलब्ध कराया जाएगा. यह एक फ़ाइल, http या https यूआरएल होना चाहिए. रीडायरेक्ट किए गए यूआरएल को इसमें शामिल किया जाता है. पुष्टि करने की सुविधा काम नहीं करती. urls पैरामीटर की मदद से, ज़्यादा फ़्लेक्सिबिलिटी हासिल की जा सकती है. इसकी मदद से, फ़ेच करने के लिए वैकल्पिक यूआरएल तय किए जा सकते हैं. यूआरएल `.jar` पर खत्म होना चाहिए.

urls स्ट्रिंग की सूची; ज़रूरी नहीं

यह एक ऐसी फ़ाइल के यूआरएल की सूची होती है जिसे Bazel के लिए उपलब्ध कराया जाएगा. हर एंट्री एक फ़ाइल, http या https यूआरएल होनी चाहिए. रीडायरेक्ट किए गए यूआरएल को इसमें शामिल किया जाता है. पुष्टि करने की सुविधा काम नहीं करती. जब तक कोई यूआरएल काम नहीं करता, तब तक यूआरएल को क्रम से आज़माया जाता है. इसलिए, आपको सबसे पहले स्थानीय मिरर की सूची बनानी चाहिए. अगर सभी डाउनलोड पूरे नहीं होते हैं, तो नियम लागू नहीं होगा. सभी यूआरएल `.jar` पर खत्म होने चाहिए.