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

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

@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_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`	डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी नहीं यह विकल्प कस्टम ऑथराइज़ेशन पैटर्न के लिए, डिक्ट मैपिंग होस्ट नेम का इस्तेमाल करता है. अगर इस डिक्ट में किसी यूआरएल का होस्ट नाम मौजूद है, तो http अनुरोध के लिए ऑथराइज़ेशन हेडर जनरेट करते समय, वैल्यू का इस्तेमाल पैटर्न के तौर पर किया जाएगा. इससे कई सामान्य क्लाउड स्टोरेज सेवा देने वाली कंपनियों में इस्तेमाल होने वाली कस्टम ऑथराइज़ेशन स्कीम का इस्तेमाल किया जा सकता है. फ़िलहाल, इस पैटर्न में दो टोकन इस्तेमाल किए जा सकते हैं: `<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 फ़ाइलों से अलग करने के लिए ठीक से काम कर सकता है. बिल्ड_file या बिल्ड_file_content में से किसी एक को तय किया जा सकता है, लेकिन दोनों को नहीं.
`build_file_content`	स्ट्रिंग; ज़रूरी नहीं इस रिपॉज़िटरी के लिए BUILD फ़ाइल का कॉन्टेंट. बिल्ड_file या बिल्ड_file_content में से किसी एक को तय किया जा सकता है, लेकिन दोनों को नहीं.
`canonical_id`	स्ट्रिंग; ज़रूरी नहीं संग्रह की एक कैननिकल आईडी डाउनलोड की गई. अगर बताया गया हो और वह खाली न हो, तो बज़ल कैश मेमोरी से संग्रह को तब तक नहीं लेगा, जब तक कि उसी कैननिकल आईडी वाले अनुरोध करके उसे कैश मेमोरी में नहीं जोड़ा गया हो.
`integrity`	स्ट्रिंग; ज़रूरी नहीं डाउनलोड की गई फ़ाइल के सबरिसोर्स इंटेग्रिटी फ़ॉर्मैट में अपेक्षित चेकसम. यह डाउनलोड की गई फ़ाइल के चेकसम से मेल खाना चाहिए. _चेकसम को छोड़ना, सुरक्षा का जोखिम है क्योंकि रिमोट फ़ाइलें बदल सकती हैं._ इस फ़ील्ड को छोड़ने से आपका बिल्ड नॉन-हर्मेटिक बन जाएगा. डेवलपमेंट को आसान बनाना ज़रूरी नहीं है, लेकिन शिपिंग से पहले इस एट्रिब्यूट या `sha256` को सेट किया जाना चाहिए.
`netrc`	स्ट्रिंग; ज़रूरी नहीं पुष्टि करने के लिए इस्तेमाल की जाने वाली .netrc फ़ाइल की जगह
`patch_args`	स्ट्रिंग की सूची; ज़रूरी नहीं पैच टूल को दिए गए तर्क. डिफ़ॉल्ट तौर पर -p0 होता है. हालांकि, आम तौर पर git से जनरेट हुए पैच के लिए -p1 की ज़रूरत होती है. अगर एक से ज़्यादा -p आर्ग्युमेंट तय किए गए हैं, तो आखिरी वाला लागू होगा.अगर -p के अलावा अन्य आर्ग्युमेंट तय किए गए हैं, तो Bazel, Bazel-नेटिव पैच लागू करने के बजाय, पैच कमांड लाइन टूल इस्तेमाल करने लगेगा. पैच कमांड लाइन टूल और Patch_tool एट्रिब्यूट के लिए वापस आने पर, `patch` का इस्तेमाल किया जाएगा. इससे सिर्फ़ `पैच` एट्रिब्यूट में मौजूद पैच फ़ाइलों पर असर पड़ता है.
`patch_cmds`	स्ट्रिंग की सूची; ज़रूरी नहीं पैच लागू होने के बाद, Linux/Macos पर बैश निर्देशों का क्रम लागू किया जाता है.
`patch_cmds_win`	स्ट्रिंग की सूची; ज़रूरी नहीं पैच लागू होने के बाद, Windows पर लागू किए जाने वाले PowersShe के निर्देशों का क्रम. अगर यह एट्रिब्यूट सेट नहीं है, तो Windows पर पैच_cmds चलाया जाएगा. इसके लिए, बैश बाइनरी का मौजूद होना ज़रूरी है.
`patch_tool`	स्ट्रिंग; ज़रूरी नहीं इस्तेमाल करने के लिए, पैच(1) सुविधा. अगर यह तय किया जाता है, तो Bazel, Bazel-नेटिव पैच लागू करने के बजाय, बताए गए पैच टूल का इस्तेमाल करेगा.
`patches`	लेबल की सूची; वैकल्पिक उन फ़ाइलों की सूची जिन्हें संग्रह से निकालने के बाद पैच के तौर पर लागू किया जाना है. डिफ़ॉल्ट रूप से, यह Bazel-नेटिव पैच लागू करने की प्रोसेस का इस्तेमाल करता है, जो फ़ज़ मैच और बाइनरी पैच के साथ काम नहीं करता. हालांकि, अगर `patch_tool` एट्रिब्यूट के बारे में बताया गया है या `patch_orgs` एट्रिब्यूट में `-p` के अलावा दूसरे तर्क मौजूद हैं, तो Bazel, पैच कमांड लाइन टूल का इस्तेमाल करेगा.
`remote_patch_strip`	पूर्णांक; ज़रूरी नहीं रिमोट पैच में फ़ाइल के नाम से हटाए जाने वाले लीडिंग स्लैश की संख्या.
`remote_patches`	डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी नहीं पैच फ़ाइल यूआरएल का मैप, इसकी इंटिग्रिटी वैल्यू पर लागू होता है. इन्हें संग्रह से निकालने के बाद और `patches` एट्रिब्यूट से पैच फ़ाइलें लागू करने से पहले लागू किया जाता है. यह Bazel-native पैच लागू करने की प्रक्रिया का इस्तेमाल करता है. आप `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/` डायरेक्ट्री शामिल है. इसके तहत `src/`, `lib/डायरेक्ट्री', और `test/` फ़ाइल हैं. इनमें वह कोड मौजूद होता है जिसे आपको बनाना है. `strip_prefix = "foo-lib-1.2.3"` को तय करें, ताकि `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.xz"`, `"txz"`, `"tar.zst"`, `bxz`, `"tar.zst"`, `bz`.
`url`	स्ट्रिंग; ज़रूरी नहीं उस फ़ाइल का यूआरएल जिसे Bazel को उपलब्ध कराया जाएगा. यह फ़ाइल, एचटीटीपी या एचटीटीपीएस यूआरएल होना चाहिए. रीडायरेक्ट का पालन किया जाता है. पुष्टि नहीं की जा सकती. यूआरएल पैरामीटर की मदद से ज़्यादा सुविधाएं मिल सकती हैं. इससे फ़ेच करने के लिए वैकल्पिक यूआरएल तय किए जा सकते हैं.
`urls`	स्ट्रिंग की सूची; ज़रूरी नहीं उस फ़ाइल के यूआरएल की सूची जिसे Bazel को उपलब्ध कराया जाएगा. हर एंट्री एक फ़ाइल, एचटीटीपी या एचटीटीपीएस यूआरएल होनी चाहिए. रीडायरेक्ट का पालन किया जाता है. पुष्टि नहीं की जा सकती. यूआरएल को तब तक क्रम में लगाने की कोशिश की जाती है, जब तक कोई यूआरएल सही नहीं हो जाता. इसलिए, स्थानीय डुप्लीकेट वर्शन बनाने से पहले, यूआरएल की सूची बना लेनी चाहिए. अगर सभी फ़ाइलें डाउनलोड नहीं हो पाती हैं, तो नियम लागू नहीं होगा.
`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 पर उपलब्ध है. इसके बाद, इन्हें अपनी वर्कस्पेस फ़ाइल में जोड़ा जा सकता है:

  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`	डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी नहीं यह विकल्प कस्टम ऑथराइज़ेशन पैटर्न के लिए, डिक्ट मैपिंग होस्ट नेम का इस्तेमाल करता है. अगर इस डिक्ट में किसी यूआरएल का होस्ट नाम मौजूद है, तो http अनुरोध के लिए ऑथराइज़ेशन हेडर जनरेट करते समय, वैल्यू का इस्तेमाल पैटर्न के तौर पर किया जाएगा. इससे कई सामान्य क्लाउड स्टोरेज सेवा देने वाली कंपनियों में इस्तेमाल होने वाली कस्टम ऑथराइज़ेशन स्कीम का इस्तेमाल किया जा सकता है. फ़िलहाल, इस पैटर्न में दो टोकन इस्तेमाल किए जा सकते हैं: `<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`	स्ट्रिंग; ज़रूरी नहीं संग्रह की एक कैननिकल आईडी डाउनलोड की गई. अगर बताया गया हो और वह खाली न हो, तो बज़ल कैश मेमोरी से संग्रह को तब तक नहीं लेगा, जब तक कि उसी कैननिकल आईडी वाले अनुरोध करके उसे कैश मेमोरी में नहीं जोड़ा गया हो.
`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 को उपलब्ध कराया जाएगा. यह फ़ाइल, एचटीटीपी या एचटीटीपीएस यूआरएल होना चाहिए. रीडायरेक्ट का पालन किया जाता है. पुष्टि नहीं की जा सकती. यूआरएल पैरामीटर की मदद से ज़्यादा सुविधाएं मिल सकती हैं. इससे फ़ेच करने के लिए वैकल्पिक यूआरएल तय किए जा सकते हैं.
`urls`	स्ट्रिंग की सूची; ज़रूरी नहीं उस फ़ाइल के यूआरएल की सूची जिसे Bazel को उपलब्ध कराया जाएगा. हर एंट्री एक फ़ाइल, एचटीटीपी या एचटीटीपीएस यूआरएल होनी चाहिए. रीडायरेक्ट का पालन किया जाता है. पुष्टि नहीं की जा सकती. यूआरएल को तब तक क्रम में लगाने की कोशिश की जाती है, जब तक कोई यूआरएल सही नहीं हो जाता. इसलिए, स्थानीय डुप्लीकेट वर्शन बनाने से पहले, यूआरएल की सूची बना लेनी चाहिए. अगर सभी फ़ाइलें डाउनलोड नहीं हो पाती हैं, तो नियम लागू नहीं होगा.

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 को डिपेंडेंसी के तौर पर तय करेंगे.

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

विशेषताएं

`name`	नाम; ज़रूरी है डेटा स्टोर करने की इस जगह के लिए यूनीक नाम.
`auth_patterns`	डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी नहीं यह विकल्प कस्टम ऑथराइज़ेशन पैटर्न के लिए, डिक्ट मैपिंग होस्ट नेम का इस्तेमाल करता है. अगर इस डिक्ट में किसी यूआरएल का होस्ट नाम मौजूद है, तो http अनुरोध के लिए ऑथराइज़ेशन हेडर जनरेट करते समय, वैल्यू का इस्तेमाल पैटर्न के तौर पर किया जाएगा. इससे कई सामान्य क्लाउड स्टोरेज सेवा देने वाली कंपनियों में इस्तेमाल होने वाली कस्टम ऑथराइज़ेशन स्कीम का इस्तेमाल किया जा सकता है. फ़िलहाल, इस पैटर्न में दो टोकन इस्तेमाल किए जा सकते हैं: `<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`	स्ट्रिंग; ज़रूरी नहीं संग्रह की एक कैननिकल आईडी डाउनलोड की गई. अगर बताया गया हो और वह खाली न हो, तो बज़ल कैश मेमोरी से संग्रह को तब तक नहीं लेगा, जब तक कि उसी कैननिकल आईडी वाले अनुरोध करके उसे कैश मेमोरी में नहीं जोड़ा गया हो.
`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 को छोड़ना, सुरक्षा का जोखिम है क्योंकि रिमोट फ़ाइलें बदल सकती हैं._ इस फ़ील्ड को छोड़ने से आपका बिल्ड नॉन-हर्मेटिक बन जाएगा. ऐप्लिकेशन के डेवलपमेंट को आसान बनाना ज़रूरी नहीं है, लेकिन शिपिंग से पहले इस एट्रिब्यूट या `पूरी सुरक्षा देने की सुविधा` को सेट किया जाना चाहिए.
`url`	स्ट्रिंग; ज़रूरी नहीं उस फ़ाइल का यूआरएल जिसे Bazel को उपलब्ध कराया जाएगा. यह फ़ाइल, एचटीटीपी या एचटीटीपीएस यूआरएल होना चाहिए. रीडायरेक्ट का पालन किया जाता है. पुष्टि नहीं की जा सकती. यूआरएल पैरामीटर की मदद से ज़्यादा सुविधाएं मिल सकती हैं. इससे फ़ेच करने के लिए वैकल्पिक यूआरएल तय किए जा सकते हैं. यूआरएल के आखिर में `.jar` होना चाहिए.
`urls`	स्ट्रिंग की सूची; ज़रूरी नहीं उस फ़ाइल के यूआरएल की सूची जिसे Bazel को उपलब्ध कराया जाएगा. हर एंट्री एक फ़ाइल, एचटीटीपी या एचटीटीपीएस यूआरएल होनी चाहिए. रीडायरेक्ट का पालन किया जाता है. पुष्टि नहीं की जा सकती. यूआरएल को तब तक क्रम में लगाने की कोशिश की जाती है, जब तक कोई यूआरएल सही नहीं हो जाता. इसलिए, स्थानीय डुप्लीकेट वर्शन बनाने से पहले, यूआरएल की सूची बना लेनी चाहिए. अगर सभी फ़ाइलें डाउनलोड नहीं हो पाती हैं, तो नियम लागू नहीं होगा. सभी यूआरएल के आखिर में `.jar` होना चाहिए.