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

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

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

सेटअप

इन नियमों का इस्तेमाल करने के लिए, उन्हें अपनी WORKSPACE फ़ाइल में इस तरह लोड करें:

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

ये नियम, नेटिव एचटीटीपी नियमों के बेहतर वर्शन हैं और आखिरकार नेटिव नियमों की जगह ले लेंगे.

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 रखा जा सकता है. जैसे, 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 पर पावरशेल कमांड का क्रम. अगर यह एट्रिब्यूट सेट नहीं है, तो patch_cmds को Windows पर चलाया जाएगा. इसके लिए, 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 डिकशनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी है

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

उदाहरण के लिए, "@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`). अगर तय किया गया प्रीफ़िक्स, संग्रह में मौजूद किसी डायरेक्ट्री से मेल नहीं खाता है, तो Bagel एक गड़बड़ी दिखाएगा.

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

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

उदाहरण के लिए, "@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)

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

डाउनलोड की गई फ़ाइलों में .Jर एक्सटेंशन होना ज़रूरी है.

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

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

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

auth_patterns = {
    "storage.cloudprovider.com": "Bearer <password>"
}
नेटवर्क: 
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 डिकशनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी है

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

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

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

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

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

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

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

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