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

ये फ़ंक्शन, @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 फ़ाइल में इन repo नियमों को सीधे तौर पर कॉल किया जा सकता है:

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

http_archive

load("@bazel//tools/build_defs/repo:http.bzl", "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 रिपॉज़िटरी में मौजूद टारगेट, इस टारगेट पर निर्भर हो सकते हैं. इसके लिए, ~/chat-app/WORKSPACE में ये लाइनें जोड़ें:

  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 फ़ील्ड की वैल्यू के तौर पर सेट किया जाता है. एट्रिब्यूट और netrc का उदाहरण, जो OAuth2 की सुविधा वाले एपीआई से, http डाउनलोड करने के लिए, बियरर टोकन का इस्तेमाल करता है: 

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 पर Pat_cmds का इस्तेमाल किया जाएगा. इसके लिए, Bash बाइनरी का मौजूद होना ज़रूरी है.

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

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

patches लेबल की सूची; ज़रूरी नहीं

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

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

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

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

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

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

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

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

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

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

सिर्फ़ `WORKSPACE` कॉन्टेक्स्ट में: लोकल डेटा स्टोर करने की जगह के नाम से ग्लोबल डेटा स्टोर करने की जगह के नाम में बदलने वाली डिक्शनरी. इससे, इस रिपॉज़िटरी की डिपेंडेंसी के लिए, वर्कस्पेस डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है. उदाहरण के लिए, "@foo": "@bar" वाली एंट्री से पता चलता है कि इस रिपॉज़िटरी को किसी भी समय `@foo` पर निर्भर रहना होगा. जैसे, `@foo//some:target` पर निर्भर रहना होगा. यह असल में, दुनिया भर में बताए गए `@bar` (`@bar//some:target`) में उस डिपेंडेंसी को हल करना चाहिए. यह एट्रिब्यूट, `MODULE.bazel` कॉन्टेक्स्ट में काम नहीं करता. ऐसा तब होता है, जब मॉड्यूल एक्सटेंशन के लागू करने वाले फ़ंक्शन में रिपॉज़िटरी नियम को लागू किया जाता है.

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 स्ट्रिंग; ज़रूरी नहीं

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

urls स्ट्रिंग की सूची; वैकल्पिक

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

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

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

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

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

एनवायरमेंट वैरिएबल

डेटा स्टोर करने की जगह का यह नियम, इन एनवायरमेंट वैरिएबल पर निर्भर करता है:

  • BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID

http_file

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

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

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

उदाहरण: मान लें कि आपको अपने कस्टम नियमों के लिए debian पैकेज की ज़रूरत है. यह पैकेज 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 फ़ील्ड की वैल्यू के तौर पर सेट किया जाता है. एट्रिब्यूट और netrc का उदाहरण, जो OAuth2 की सुविधा वाले एपीआई से, http डाउनलोड करने के लिए, बियरर टोकन का इस्तेमाल करता है: 

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 डिकशनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी नहीं

सिर्फ़ `WORKSPACE` कॉन्टेक्स्ट में: लोकल डेटा स्टोर करने की जगह के नाम से ग्लोबल डेटा स्टोर करने की जगह के नाम में बदलने वाली डिक्शनरी. इससे, इस रिपॉज़िटरी की डिपेंडेंसी के लिए फ़ाइल फ़ोल्डर डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है. उदाहरण के लिए, "@foo": "@bar" वाली एंट्री से पता चलता है कि इस रिपॉज़िटरी में, किसी भी समय `@foo` पर निर्भरता हो सकती है. जैसे, `@foo//some:target` पर निर्भरता. यह असल में, दुनिया भर में बताए गए `@bar` (`@bar//some:target`) में उस निर्भरता को हल करनी चाहिए. यह एट्रिब्यूट, `MODULE.bazel` कॉन्टेक्स्ट में काम नहीं करता. ऐसा तब होता है, जब मॉड्यूल एक्सटेंशन के लागू करने वाले फ़ंक्शन में रिपॉज़िटरी नियम को लागू किया जाता है.

sha256 स्ट्रिंग; वैकल्पिक

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

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

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

urls स्ट्रिंग की सूची; वैकल्पिक

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

एनवायरमेंट के अलग-अलग वैरिएंट

डेटा स्टोर करने की जगह का यह नियम, इन एनवायरमेंट वैरिएबल पर निर्भर करता है:

  • BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID

http_jar

load("@bazel//tools/build_defs/repo:http.bzl", "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",
  )

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

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

एट्रिब्यूट

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

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

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

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

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 स्ट्रिंग; ज़रूरी नहीं

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

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

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

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

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

repo_mapping शब्दकोश: स्ट्रिंग -> स्ट्रिंग; वैकल्पिक

सिर्फ़ `WORKSPACE` कॉन्टेक्स्ट में: लोकल डेटा स्टोर करने की जगह के नाम से ग्लोबल डेटा स्टोर करने की जगह के नाम में बदलने वाली डिक्शनरी. इससे, इस रिपॉज़िटरी की डिपेंडेंसी के लिए, वर्कस्पेस डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है. उदाहरण के लिए, "@foo": "@bar" वाली एंट्री से पता चलता है कि इस रिपॉज़िटरी में, किसी भी समय `@foo` पर निर्भरता हो सकती है. जैसे, `@foo//some:target` पर निर्भरता. यह असल में, दुनिया भर में बताए गए `@bar` (`@bar//some:target`) में उस निर्भरता को हल करनी चाहिए. यह एट्रिब्यूट, `MODULE.bazel` कॉन्टेक्स्ट में काम नहीं करता. ऐसा तब होता है, जब मॉड्यूल एक्सटेंशन के लागू करने वाले फ़ंक्शन में रिपॉज़िटरी नियम को लागू किया जाता है.

sha256 स्ट्रिंग; वैकल्पिक

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

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

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

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

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

एनवायरमेंट के अलग-अलग वैरिएंट

यह रिपॉज़िटरी नियम, इन एनवायरमेंट वैरिएबल पर निर्भर करता है:

  • BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID