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

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

ये फ़ंक्शन, @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 नियमों के बेहतर वर्शन हैं. आने वाले समय में, ये नेटिव नियमों की जगह ले लेंगे.

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_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_FULLS_URLS_AS_DEFAULT_CANONICAL_ID=0 से बंद किया जा सकता है.
integrity	स्ट्रिंग; ज़रूरी नहीं डाउनलोड की गई फ़ाइल के सब-सोर्स इंटिग्रिटी फ़ॉर्मैट में, उम्मीद के मुताबिक चेकसम. यह डाउनलोड की गई फ़ाइल के चेकसम से मेल खाना चाहिए. _चेकसम को शामिल न करना सुरक्षा के लिहाज़ से जोखिम भरा है, क्योंकि रिमोट फ़ाइलों में बदलाव हो सकता है._ इस फ़ील्ड को शामिल न करने पर, आपका बिल्ड पूरी तरह से सुरक्षित नहीं रहेगा. डेवलपमेंट को आसान बनाना ज़रूरी नहीं है. हालांकि, शिपिंग से पहले इस एट्रिब्यूट या `sha256` को सेट करना ज़रूरी है.
netrc	स्ट्रिंग; ज़रूरी नहीं पुष्टि करने के लिए इस्तेमाल की जाने वाली .netrc फ़ाइल की जगह
patch_args	स्ट्रिंग की सूची; ज़रूरी नहीं पैच टूल को दिए गए आर्ग्युमेंट. डिफ़ॉल्ट रूप से -p0 पर सेट होता है. हालांकि, git से जनरेट किए गए पैच के लिए आम तौर पर -p1 की ज़रूरत होगी. अगर एक से ज़्यादा -p आर्ग्युमेंट तय किए गए हैं, तो आखिरी वाला आर्ग्युमेंट लागू होगा.अगर -p के अलावा किसी अन्य आर्ग्युमेंट का इस्तेमाल किया जाता है, तो Basel-नेटिव पैच को लागू करने के बजाय, पैच कमांड लाइन टूल का इस्तेमाल करेगा. अगर पैच कमांड लाइन टूल का इस्तेमाल किया जा रहा है और patch_tool एट्रिब्यूट की वैल्यू नहीं दी गई है, तो `patch` का इस्तेमाल किया जाएगा. इसका असर सिर्फ़ `patches` एट्रिब्यूट में मौजूद पैच फ़ाइलों पर पड़ता है.
patch_cmds	स्ट्रिंग की सूची; ज़रूरी नहीं पैच लागू होने के बाद, Linux/Macos पर लागू किए जाने वाले Bash कमांड का क्रम.
patch_cmds_win	स्ट्रिंग की सूची; ज़रूरी नहीं पैच लागू होने के बाद, Windows पर लागू किए जाने वाले Powershell निर्देशों का क्रम. अगर यह एट्रिब्यूट सेट नहीं है, तो patch_cmds को Windows पर चलाया जाएगा. इसके लिए, Bash बाइनरी मौजूद होनी चाहिए.
patch_tool	स्ट्रिंग; वैकल्पिक इस्तेमाल करने के लिए पैच(1) की सुविधा. अगर यह बताया जाता है, तो Basel-नेटिव पैच को लागू करने के बजाय, Basel के बताए गए पैच टूल का इस्तेमाल करेगा.
patches	लेबल की सूची; ज़रूरी नहीं उन फ़ाइलों की सूची जिन्हें संग्रह को निकालने के बाद, पैच के तौर पर लागू करना है. डिफ़ॉल्ट रूप से, यह Bazel-नेटिव पैच लागू करने का तरीका इस्तेमाल करता है. यह फ़ज़ मैच और बाइनरी पैच के साथ काम नहीं करता. हालांकि, अगर `patch_tool` एट्रिब्यूट की वैल्यू दी गई है या `patch_args` एट्रिब्यूट में `-p` के अलावा कोई अन्य आर्ग्युमेंट है, तो 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 को शामिल न करना सुरक्षा के लिहाज़ से जोखिम भरा है, क्योंकि रिमोट फ़ाइलों में बदलाव हो सकता है._ इस फ़ील्ड को शामिल न करने पर, आपका बिल्ड पूरी तरह से सुरक्षित नहीं रहेगा. डेवलपमेंट को आसान बनाने के लिए, यह एट्रिब्यूट देना ज़रूरी नहीं है. हालांकि, शिपिंग से पहले, इस एट्रिब्यूट या `इंटिग्रिटी` को सेट किया जाना चाहिए.
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 फ़ील्ड की वैल्यू के तौर पर सेट किया जाता है. एट्रिब्यूट और 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_FULLS_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 के तौर पर उपलब्ध कराता है

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

उदाहरण: मान लें कि मौजूदा रिपॉज़िटरी में चैट प्रोग्राम का सोर्स कोड है, जो डायरेक्ट्री ~/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",
  )

टारगेट इस जार पर निर्भर रहने के लिए, @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>" } नेटवर्क: machine storage.cloudprovider.com password RANDOM-TOKEN फ़ाइनल एचटीटीपी अनुरोध में यह हेडर होगा: Authorization: Bearer RANDOM-TOKEN
canonical_id	स्ट्रिंग; ज़रूरी नहीं डाउनलोड की गई फ़ाइल का कैननिकल आईडी. अगर कैश मेमोरी में सेव की गई फ़ाइल का कैननिकल आईडी दिया गया है और वह खाली नहीं है, तो Bazel उस फ़ाइल को कैश मेमोरी से तब तक नहीं लेगा, जब तक कि उसे उसी कैननिकल आईडी वाले अनुरोध से कैश मेमोरी में नहीं जोड़ा गया है. अगर कोई वैल्यू नहीं दी गई है या वह खाली है, तो Bazel डिफ़ॉल्ट रूप से फ़ाइल के यूआरएल का इस्तेमाल, कैननिकल आईडी के तौर पर करता है. इससे हैश को अपडेट किए बिना, यूआरएल को अपडेट करने में होने वाली आम गलती को पकड़ने में मदद मिलती है. इस वजह से, ऐसे बिल्ड बन जाते हैं जो स्थानीय तौर पर काम करते हैं, लेकिन कैश मेमोरी में सेव की गई फ़ाइल के बिना, मशीन पर फ़ेल हो जाते हैं. इस व्यवहार को --repo_env=BAZEL_HTTP_FULLS_URLS_AS_DEFAULT_CANONICAL_ID=0 से बंद किया जा सकता है.
downloaded_file_name	स्ट्रिंग; ज़रूरी नहीं डाउनलोड किए गए jar फ़ाइल को असाइन किया गया फ़ाइल नाम
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 पैरामीटर की मदद से ज़्यादा सुविधाएं मिल सकती हैं. इसकी मदद से, फ़ेच करने के लिए वैकल्पिक यूआरएल तय किए जा सकते हैं. यूआरएल का आखिर में `.jar` होना चाहिए.
urls	स्ट्रिंग की सूची; ज़रूरी नहीं किसी फ़ाइल के यूआरएल की सूची, जिसे Bazel के लिए उपलब्ध कराया जाएगा. हर एंट्री, कोई फ़ाइल, http या https यूआरएल होनी चाहिए. दूसरे वेबलिंक पर भेजने वाले यूआरएल को भी फ़ॉलो किया जाता है. पुष्टि करने की सुविधा काम नहीं करती. यूआरएल को क्रम से तब तक आज़माया जाता है, जब तक कि कोई एक काम न कर जाए. इसलिए, आपको पहले लोकल मिरर की सूची बनानी चाहिए. अगर सभी डाउनलोड नहीं हो पाते हैं, तो नियम लागू नहीं होगा. सभी यूआरएल के आखिर में `.jar` होना चाहिए.