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

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

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)

कंप्रेस की गई संग्रह फ़ाइल के रूप में Basel का डेटा स्टोर करने की जगह डाउनलोड करता है, उसे डीकंप्रेस करता है, और अपने टारगेट को बाइंडिंग के लिए उपलब्ध कराता है.

यह इन फ़ाइल एक्सटेंशन के साथ काम करता है: "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`	String; ज़रूरी नहीं रिपॉज़िटरी डायरेक्ट्री के हिसाब से डेस्टिनेशन डायरेक्ट्री. संग्रह में मौजूद फ़ाइल पाथ पर `strip_prefix` (अगर कोई है) लागू करने के बाद, संग्रह को इस डायरेक्ट्री में अनपैक किया जाएगा. उदाहरण के लिए, अगर `add_prefix = "bar"` और `strip_prefix = "foo-1.2.3"` है, तो फ़ाइल `foo-1.2.3/src/foo.h` को `bar/src/foo.h` में अनपैक कर दिया जाएगा.
`auth_patterns`	शब्दकोश: स्ट्रिंग -> String; ज़रूरी नहीं होस्ट नेम को कस्टम अनुमति पैटर्न से मैप करने वाली वैकल्पिक डिक्शनरी. अगर इस डायक्शनरी में किसी यूआरएल का होस्ट नेम मौजूद है, तो एचटीटीपी अनुरोध के लिए अनुमति देने वाले हेडर को जनरेट करते समय, वैल्यू का इस्तेमाल पैटर्न के तौर पर किया जाएगा. इससे, अनुमति देने के लिए कस्टम स्कीम का इस्तेमाल किया जा सकता है. ये स्कीम, क्लाउड स्टोरेज की सेवा देने वाली कई कंपनियों के पास मौजूद होती हैं. फ़िलहाल, पैटर्न में दो टोकन काम करते हैं: `<login>` और `<password>`. इन्हें एक ही होस्ट नेम के लिए, netrc फ़ाइल में उनकी वैल्यू से बदल दिया जाता है. फ़ॉर्मैट करने के बाद, नतीजे को एचटीटीपी अनुरोध के `Authorization` फ़ील्ड की वैल्यू के तौर पर सेट किया जाता है. एट्रिब्यूट और netrc का उदाहरण, जो किसी एपीआई से एचटीटीपी डाउनलोड करने के लिए इस्तेमाल किया जाता है. यह एपीआई, OAuth2 की सुविधा के साथ काम करता है और इसमें बियरर टोकन का इस्तेमाल किया जाता है: 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`	स्ट्रिंग; ज़रूरी नहीं डाउनलोड की गई फ़ाइल का कैननिकल आईडी. अगर बताया गया है और खाली नहीं है, तो Baज़र, कैश मेमोरी से फ़ाइल नहीं लेगा, जब तक कि वह कैश मेमोरी में, उसी कैननिकल आईडी वाले अनुरोध से जोड़ा गया था. अगर यह बताया नहीं जाता या खाली होता है, तो Baज़र, डिफ़ॉल्ट रूप से फ़ाइल के यूआरएल को इस तरह इस्तेमाल करता है: कैननिकल आईडी होना चाहिए. इससे, यूआरएल को अपडेट करने के साथ-साथ हैश को अपडेट न करने की आम गलती को पकड़ने में मदद मिलती है. इस वजह से, ऐसे बिल्ड बनते हैं जो लोकल तौर पर काम करते हैं, लेकिन कैश मेमोरी में फ़ाइल न होने पर, मशीनों पर काम नहीं करते. इस व्यवहार को बंद करने के लिए, --repo_env=BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID=0 का इस्तेमाल किया जा सकता है.
`integrity`	स्ट्रिंग; ज़रूरी नहीं डाउनलोड की गई फ़ाइल के सबरिसॉर्स इंटेग्रिटी फ़ॉर्मैट में अनुमानित चेकसम. यह डाउनलोड की गई फ़ाइल के चेकसम से मेल खाना चाहिए. _चेकसम को शामिल न करना सुरक्षा के लिहाज़ से जोखिम भरा है, क्योंकि रिमोट फ़ाइलों में बदलाव हो सकता है._ इस फ़ील्ड को शामिल न करने पर, आपका बिल्ड पूरी तरह से सुरक्षित नहीं रहेगा. डेवलपमेंट करना ज़रूरी नहीं है लेकिन शिपिंग से पहले इस एट्रिब्यूट या `sha256` को सेट किया जाना चाहिए.
`netrc`	स्ट्रिंग; ज़रूरी नहीं पुष्टि करने के लिए .netrc फ़ाइल की जगह
`patch_args`	स्ट्रिंग की सूची; ज़रूरी नहीं पैच टूल को दिए गए आर्ग्युमेंट. डिफ़ॉल्ट तौर पर -p0 होता है. हालांकि, git से जनरेट किए गए पैच के लिए, आम तौर पर -p1 की ज़रूरत होती है. अगर एक से ज़्यादा -p आर्ग्युमेंट दिए जाते हैं, तो आखिरी आर्ग्युमेंट लागू होगा. अगर -p के अलावा कोई अन्य आर्ग्युमेंट दिया जाता है, तो Bazel, Bazel-नेटिव पैच लागू करने के बजाय, पैच कमांड लाइन टूल का इस्तेमाल करेगा. पैच कमांड लाइन टूल और पैच_टूल एट्रिब्यूट पर वापस जाने पर, `पैच` का इस्तेमाल किया जाएगा. इसका असर सिर्फ़ `patches` एट्रिब्यूट में मौजूद पैच फ़ाइलों पर पड़ता है.
`patch_cmds`	स्ट्रिंग की सूची; ज़रूरी नहीं पैच लागू होने के बाद, Linux/Macos पर Bash कमांड का क्रम.
`patch_cmds_win`	स्ट्रिंग की सूची; ज़रूरी नहीं पैच लागू होने के बाद, Windows पर पावरशेल कमांड का क्रम. अगर यह एट्रिब्यूट सेट नहीं है, तो Windows पर Pat_cmds का इस्तेमाल किया जाएगा. इसके लिए, Bash बाइनरी का मौजूद होना ज़रूरी है.
`patch_tool`	स्ट्रिंग; ज़रूरी नहीं इस्तेमाल की जाने वाली पैच(1) सुविधा. अगर यह जानकारी दी गई है, तो Bazel, Bazel के पैच लागू करने के बजाय, बताए गए पैच टूल का इस्तेमाल करेगा.
`patches`	लेबल की सूची; ज़रूरी नहीं उन फ़ाइलों की सूची जिन्हें संग्रह से निकालने के बाद, पैच के तौर पर लागू किया जाना है. डिफ़ॉल्ट रूप से, यह BaZ-नेटिव पैच लागू करने की सुविधा का इस्तेमाल करता है, जो फ़ज़ मैच और बाइनरी पैच के साथ काम नहीं करता. हालांकि, अगर `patch_tool` एट्रिब्यूट के बारे में बताया गया है या `patch_orgs` एट्रिब्यूट में `-p` के अलावा कोई अन्य आर्ग्युमेंट हैं, तो Baज़र, पैच कमांड लाइन टूल का इस्तेमाल करने लगेगा.
`remote_file_integrity`	शब्दकोश: स्ट्रिंग -> String; ज़रूरी नहीं फ़ाइल इंटिग्रिटी वैल्यू (वैल्यू) से मिलते-जुलते पाथ (कुंजी) का मैप. ये रिलेटिव पाथ, `remote_file_urls` एट्रिब्यूट में मौजूद फ़ाइलों (की) से मैप होने चाहिए.
`remote_file_urls`	डिक्शनरी: स्ट्रिंग -> स्ट्रिंग की सूची; ज़रूरी नहीं यूआरएल (वैल्यू) की सूची और रिलेटिव पाथ (कुंजी) का मैप, जिन्हें डाउनलोड किया जाना है और रेपो पर रखी गई फ़ाइलों के तौर पर उपलब्ध कराना है. यह तब काम आता है, जब आपको किसी मौजूदा रिपॉज़िटरी में WORKSPACE या BUILD.bazel फ़ाइलें जोड़नी हों. `पैच` एट्रिब्यूट में पैच लागू करने से पहले, फ़ाइलें डाउनलोड की जाती हैं. साथ ही, यूआरएल की सूची में एक ही फ़ाइल के सभी संभावित मिरर होने चाहिए. यूआरएल को क्रम में तब तक आज़माया जाता है, जब तक कोई एक सफल नहीं होता.
`remote_patch_strip`	Integer; ज़रूरी नहीं रिमोट पैच में, फ़ाइल के नाम से हटाए जाने वाले शुरुआती स्लैश की संख्या.
`remote_patches`	डिकशनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी नहीं पैच फ़ाइल के यूआरएल का मैप, इसकी इंटिग्रिटी वैल्यू के लिए. संग्रह को एक्सट्रैक्ट करने और `पैच` एट्रिब्यूट से पैच फ़ाइलों को लागू करने से पहले, इन्हें लागू किया जाता है. यह Bazel-नेटिव पैच लागू करने का इस्तेमाल करता है. `remote_patch_strip` की मदद से, पैच स्ट्रिप नंबर तय किया जा सकता है
`repo_mapping`	शब्दकोश: स्ट्रिंग -> String; आवश्यक लोकल रिपॉज़िटरी के नाम से लेकर ग्लोबल रिपॉज़िटरी के नाम तक का डिक्शनरी. इससे, इस रिपॉज़िटरी की डिपेंडेंसी के लिए, वर्कस्पेस डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है. उदाहरण के लिए, एक एंट्री `"@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/` डायरेक्ट्री जिनमें आपका असल कोड होता है तैयार करना है. इस्तेमाल करने के लिए, `strip_prefix = "foo-lib-1.2.3"` तय करें `foo-lib-1.2.3` डायरेक्ट्री को आपकी टॉप-लेवल डायरेक्ट्री के तौर पर इस्तेमाल करना. ध्यान दें कि अगर फ़ाइलें इस डायरेक्ट्री के बाहर हैं, तो वे खारिज कर दिया गया है और इसे ऐक्सेस नहीं किया जा सकता (उदाहरण के लिए, टॉप लेवल लाइसेंस फ़ाइल). इसमें ऐसी फ़ाइलें/डायरेक्ट्री शामिल होती हैं जो प्रीफ़िक्स से शुरू होती हैं, लेकिन डायरेक्ट्री में नहीं होतीं (उदाहरण के लिए, `foo-lib-1.2.3.release-notes`). अगर दिया गया प्रीफ़िक्स, संग्रह में मौजूद किसी डायरेक्ट्री से मेल नहीं खाता है, तो Bazel गड़बड़ी का मैसेज दिखाएगा.
`type`	String; ज़रूरी नहीं डाउनलोड की गई फ़ाइल के संग्रह का टाइप. डिफ़ॉल्ट रूप से, संग्रह का टाइप यूआरएल के फ़ाइल एक्सटेंशन से तय होता है. अगर फ़ाइल का कोई एक्सटेंशन नहीं है, तो इनमें से कोई एक एक्सटेंशन डालें: `"zip"`, `"jar"`, `"war"`, `"aar"`, `"tar"`, `"tar.gz"`, `"tgz"`, `"tar.xz"`, `"txz"`, `"tar.zst"`, `"tzst"`, `"tar.bz2"`, `"ar"`, या `"deb"`.
`url`	String; ज़रूरी नहीं किसी ऐसी फ़ाइल का यूआरएल जिसे Bazel के लिए उपलब्ध कराया जाएगा. यह फ़ाइल, http या https यूआरएल होनी चाहिए. दूसरे वेबलिंक पर भेजने वाले यूआरएल को भी फ़ॉलो किया जाता है. प्रमाणीकरण समर्थित नहीं है. urls पैरामीटर की मदद से ज़्यादा सुविधाएं मिल सकती हैं. इसकी मदद से, फ़ेच करने के लिए वैकल्पिक यूआरएल तय किए जा सकते हैं.
`urls`	स्ट्रिंग की सूची; ज़रूरी नहीं उस फ़ाइल के यूआरएल की सूची जिसे Basel को उपलब्ध कराया जाएगा. हर एंट्री कोई फ़ाइल, http या https यूआरएल होनी चाहिए. दूसरे वेबलिंक पर ले जाने वाले यूआरएल को इसमें शामिल किया जाता है. प्रमाणीकरण समर्थित नहीं है. यूआरएल को एक क्रम में तब तक आज़माया जाता है, जब तक कि एक यूआरएल सफल नहीं हो जाता. इसलिए, आपको पहले स्थानीय मिरर की सूची बनानी चाहिए. अगर सभी डाउनलोड नहीं हो पाते हैं, तो नियम लागू नहीं होगा.
`workspace_file`	लेबल; ज़रूरी नहीं इस डेटा स्टोर करने की जगह के लिए `वर्कस्पेस` फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. `workspace_file` या `workspace_file_content` में से किसी एक का इस्तेमाल किया जा सकता है. इसके अलावा, दोनों का इस्तेमाल नहीं किया जा सकता.
`workspace_file_content`	String; ज़रूरी नहीं इस रिपॉज़िटरी के लिए 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`	शब्दकोश: स्ट्रिंग -> String; ज़रूरी नहीं होस्ट नेम को कस्टम अनुमति पैटर्न से मैप करने वाली वैकल्पिक डिक्शनरी. अगर इस डिक्शनरी में किसी यूआरएल का होस्ट का नाम मौजूद है, तो वैल्यू को पैटर्न के तौर पर तब इस्तेमाल किया जाएगा, जब एचटीटीपी अनुरोध के लिए, ऑथराइज़ेशन हेडर जनरेट करना. इससे कस्टम जानकारी, अनुमति देने वाली स्कीम का इस्तेमाल, क्लाउड स्टोरेज उपलब्ध कराने वाली ज़्यादातर सामान्य कंपनियों में किया जाता है. फ़िलहाल, पैटर्न में दो टोकन इस्तेमाल किए जा सकते हैं: `<login>` और `<password>`, जिन्हें उनकी मिलती-जुलती वैल्यू से बदल दिया जाता है netrc फ़ाइल में, उसी होस्ट नाम के लिए. फ़ॉर्मैट करने के बाद, नतीजे को एचटीटीपी अनुरोध के `Authorization` फ़ील्ड की वैल्यू के तौर पर सेट किया जाता है. एट्रिब्यूट और netrc का उदाहरण, जो किसी एपीआई से एचटीटीपी डाउनलोड करने के लिए इस्तेमाल किया जाता है. यह एपीआई, OAuth2 की सुविधा के साथ काम करता है और इसमें बियरर टोकन का इस्तेमाल किया जाता है: auth_patterns = { "storage.cloudprovider.com": "Bearer <password>" } netrc: machine storage.cloudprovider.com password RANDOM-TOKEN एचटीटीपी के फ़ाइनल अनुरोध में यह हेडर होगा: Authorization: Bearer RANDOM-TOKEN
`canonical_id`	स्ट्रिंग; ज़रूरी नहीं डाउनलोड की गई फ़ाइल का कैननिकल आईडी. अगर बताया गया है और खाली नहीं है, तो Baज़र, कैश मेमोरी से फ़ाइल नहीं लेगा, जब तक कि वह कैश मेमोरी में, उसी कैननिकल आईडी वाले अनुरोध से जोड़ा गया था. अगर यह बताया नहीं जाता या खाली होता है, तो Baज़र, डिफ़ॉल्ट रूप से फ़ाइल के यूआरएल को इस तरह इस्तेमाल करता है: कैननिकल आईडी होना चाहिए. इससे, यूआरएल को अपडेट करने के साथ-साथ हैश को अपडेट न करने की आम गलती को पकड़ने में मदद मिलती है. इस वजह से, ऐसे बिल्ड बनते हैं जो लोकल तौर पर काम करते हैं, लेकिन कैश मेमोरी में फ़ाइल न होने पर, मशीनों पर काम नहीं करते. इस व्यवहार को बंद करने के लिए, --repo_env=BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID=0 का इस्तेमाल किया जा सकता है.
`downloaded_file_path`	स्ट्रिंग; ज़रूरी नहीं डाउनलोड की गई फ़ाइल के लिए पाथ असाइन किया गया
`executable`	बूलियन; ज़रूरी नहीं क्या डाउनलोड की गई फ़ाइल को एक्ज़ीक्यूटेबल बनाया जाना चाहिए.
`integrity`	String; ज़रूरी नहीं डाउनलोड की गई फ़ाइल के सबरिसॉर्स इंटेग्रिटी फ़ॉर्मैट में अनुमानित चेकसम. यह डाउनलोड की गई फ़ाइल के चेकसम से मेल खाना चाहिए. _चेकसम को शामिल न करना सुरक्षा के लिहाज़ से जोखिम भरा है, क्योंकि रिमोट फ़ाइलों में बदलाव हो सकता है._ इस फ़ील्ड को शामिल न करने पर, आपका बिल्ड पूरी तरह से सुरक्षित नहीं रहेगा. डेवलपमेंट करना ज़रूरी नहीं है लेकिन शिपिंग से पहले इस एट्रिब्यूट या `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`	स्ट्रिंग की सूची; ज़रूरी नहीं उस फ़ाइल के यूआरएल की सूची जिसे Basel को उपलब्ध कराया जाएगा. हर एंट्री कोई फ़ाइल, 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` फ़ील्ड की वैल्यू के तौर पर सेट किया जाता है. एट्रिब्यूट और netrc का उदाहरण, जो किसी एपीआई से एचटीटीपी डाउनलोड करने के लिए इस्तेमाल किया जाता है. यह एपीआई, OAuth2 की सुविधा के साथ काम करता है और इसमें बियरर टोकन का इस्तेमाल किया जाता है: auth_patterns = { "storage.cloudprovider.com": "Bearer <password>" } netrc: machine storage.cloudprovider.com password RANDOM-TOKEN एचटीटीपी के फ़ाइनल अनुरोध में यह हेडर होगा: Authorization: Bearer RANDOM-TOKEN
`canonical_id`	String; ज़रूरी नहीं डाउनलोड की गई फ़ाइल का कैननिकल आईडी. अगर बताया गया है और खाली नहीं है, तो Baज़र, कैश मेमोरी से फ़ाइल नहीं लेगा, जब तक कि वह कैश मेमोरी में, उसी कैननिकल आईडी वाले अनुरोध से जोड़ा गया था. अगर यह बताया नहीं जाता या खाली होता है, तो Baज़र, डिफ़ॉल्ट रूप से फ़ाइल के यूआरएल को इस तरह इस्तेमाल करता है: कैननिकल आईडी होना चाहिए. इससे, यूआरएल को अपडेट करने के साथ-साथ हैश को अपडेट न करने की आम गलती को पकड़ने में मदद मिलती है. इस वजह से, ऐसे बिल्ड बनते हैं जो लोकल तौर पर काम करते हैं, लेकिन कैश मेमोरी में फ़ाइल न होने पर, मशीनों पर काम नहीं करते. इस व्यवहार को बंद करने के लिए, --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 को छोड़ने के लिए, क्योंकि रिमोट फ़ाइलें बदल सकती हैं._ इसे छोड़ देना ही सबसे सही फ़ील्ड में आपका बिल्ड नॉन-हर्मेटिक बन जाएगा. डेवलपमेंट को आसान बनाने के लिए, यह एट्रिब्यूट देना ज़रूरी नहीं है. हालांकि, शिपिंग से पहले, इस एट्रिब्यूट या `इंटिग्रिटी` को सेट करना ज़रूरी है.
`url`	String; ज़रूरी नहीं किसी ऐसी फ़ाइल का यूआरएल जिसे Bazel के लिए उपलब्ध कराया जाएगा. यह फ़ाइल, http या https यूआरएल होनी चाहिए. दूसरे वेबलिंक पर ले जाने वाले यूआरएल को इसमें शामिल किया जाता है. प्रमाणीकरण समर्थित नहीं है. इस सुविधा का इस्तेमाल करने पर, यूआरएल पैरामीटर को ज़्यादा आसानी से इस्तेमाल किया जा सकता है का इस्तेमाल करें. यूआरएल के आखिर में `.jar` होना चाहिए.
`urls`	स्ट्रिंग की सूची; ज़रूरी नहीं किसी फ़ाइल के यूआरएल की सूची, जिसे Bazel के लिए उपलब्ध कराया जाएगा. हर एंट्री, कोई फ़ाइल, http या https यूआरएल होनी चाहिए. दूसरे वेबलिंक पर ले जाने वाले यूआरएल को इसमें शामिल किया जाता है. प्रमाणीकरण समर्थित नहीं है. यूआरएल को क्रम से तब तक आज़माया जाता है, जब तक कि कोई एक काम न कर जाए. इसलिए, आपको सबसे पहले लोकल मिरर की सूची बनानी चाहिए. अगर सभी डाउनलोड नहीं हो पाते हैं, तो नियम लागू नहीं होगा. सभी यूआरएल के आखिर में `.jar` होना चाहिए.