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

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है किसी समस्या की शिकायत करें सोर्स देखें रात · 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_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` लागू करने के बाद, संग्रह को इस डायरेक्ट्री में अनपैक किया जाएगा (अगर कोई हो). उदाहरण के लिए, फ़ाइल `foo-1.2.3/src/foo.h` को `bar/src/foo.h` में अनपैक किया जाएगा अगर `add_prefix = "bar"` और `strip_prefix = "foo-1.2.3"`.
`auth_patterns`	शब्दकोश: स्ट्रिंग -> String; ज़रूरी नहीं यह एक ऐसा लिखवाने की सुविधा है जो होस्ट के नामों को कस्टम ऑथराइज़ेशन पैटर्न के साथ मैप करती है. अगर इस डिक्शनरी में किसी यूआरएल का होस्ट का नाम मौजूद है, तो वैल्यू को पैटर्न के तौर पर तब इस्तेमाल किया जाएगा, जब एचटीटीपी अनुरोध के लिए, ऑथराइज़ेशन हेडर जनरेट करना. इससे कस्टम कस्टम पैरामीटर अनुमति देने वाली स्कीम का इस्तेमाल, क्लाउड स्टोरेज उपलब्ध कराने वाली ज़्यादातर सामान्य कंपनियों में किया जाता है. फ़िलहाल, पैटर्न में दो टोकन इस्तेमाल किए जा सकते हैं: `<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.new-repo-name जैसा कुछ इस तरह से काम करता है कि इसे रिपॉज़िटरी की असल BUILD फ़ाइलों से अलग किया जा सके. बिल्ड_फ़ाइल या बिल्ड_file_content में से कोई एक तय किया जा सकता है, लेकिन दोनों को नहीं.
`build_file_content`	String; ज़रूरी नहीं इस डेटा स्टोर करने की जगह के लिए BUILD फ़ाइल का कॉन्टेंट. बिल्ड_फ़ाइल या बिल्ड_file_content में से कोई एक तय किया जा सकता है, लेकिन दोनों को नहीं.
`canonical_id`	String; ज़रूरी नहीं डाउनलोड की गई फ़ाइल का कैननिकल आईडी. अगर बताया गया है और खाली नहीं है, तो Baज़र, कैश मेमोरी से फ़ाइल नहीं लेगा, जब तक कि वह कैश मेमोरी में, उसी कैननिकल आईडी वाले अनुरोध से जोड़ा गया था. अगर यह बताया नहीं जाता या खाली होता है, तो Baज़र, डिफ़ॉल्ट रूप से फ़ाइल के यूआरएल को इस तरह इस्तेमाल करता है: कैननिकल आईडी होना चाहिए. इससे यूआरएल को अपडेट किए बिना, आम तौर पर होने वाली गलती का पता लगाने में मदद मिलती है साथ ही, हैश को अपडेट भी करता है. इससे ऐसे बिल्ड मिलते हैं जो लोकल तौर पर काम करते हैं, लेकिन बिना कैश मेमोरी वाली फ़ाइल नहीं है. इस व्यवहार को इससे बंद किया जा सकता है: --repo_env=BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID=0.
`integrity`	String; ज़रूरी नहीं डाउनलोड की गई फ़ाइल के उप-रिसॉर्स इंटेग्रिटी फ़ॉर्मैट में अनुमानित चेकसम. यह डाउनलोड की गई फ़ाइल के चेकसम से मेल खाना चाहिए. _यह एक सुरक्षा जोखिम है चेकसम को छोड़ने के लिए, क्योंकि रिमोट फ़ाइलें बदल सकती हैं._ बेहतर होगा कि आप इसे छोड़ दें फ़ील्ड में आपका बिल्ड नॉन-हर्मेटिक बन जाएगा. डेवलपमेंट करना ज़रूरी नहीं है लेकिन शिपिंग से पहले इस एट्रिब्यूट या `sha256` को सेट किया जाना चाहिए.
`netrc`	String; ज़रूरी नहीं पुष्टि करने के लिए .netrc फ़ाइल की जगह
`patch_args`	स्ट्रिंग की सूची; ज़रूरी नहीं पैच टूल को दिए गए आर्ग्युमेंट. डिफ़ॉल्ट तौर पर -p0 होता है. हालांकि, git से जनरेट किए गए पैच के लिए, आम तौर पर -p1 की ज़रूरत होती है. अगर एक से ज़्यादा -p आर्ग्युमेंट तय किए गए हैं, तो आखिरी वाला आर्ग्युमेंट लागू होगा.अगर -p के अलावा किसी अन्य आर्ग्युमेंट के बारे में बताया जाता है, तो Basel-नेटिव पैच को लागू करने के बजाय, पैच कमांड लाइन टूल का इस्तेमाल करेगा. पैच कमांड लाइन टूल और पैच_टूल एट्रिब्यूट पर वापस जाने पर, `पैच` का इस्तेमाल किया जाएगा. इससे सिर्फ़ `पैच` एट्रिब्यूट में मौजूद पैच फ़ाइलों पर असर पड़ता है.
`patch_cmds`	स्ट्रिंग की सूची; ज़रूरी नहीं पैच लागू होने के बाद, Linux/Macos पर Bash कमांड का क्रम.
`patch_cmds_win`	स्ट्रिंग की सूची; ज़रूरी नहीं पैच लागू होने के बाद, Windows पर पावरशेल कमांड का क्रम. अगर यह एट्रिब्यूट सेट नहीं है, तो Windows पर Patch_cmds का इस्तेमाल किया जाएगा. इसके लिए, Bash बाइनरी का मौजूद होना ज़रूरी है.
`patch_tool`	String; ज़रूरी नहीं इस्तेमाल की जाने वाली पैच(1) सुविधा. अगर इसका इस्तेमाल किया जा रहा है, तो Basel-नेटिव पैच को लागू करने के बजाय, Basel के बताए गए पैच टूल का इस्तेमाल किया जाएगा.
`patches`	लेबल की सूची; ज़रूरी नहीं उन फ़ाइलों की सूची जिन्हें संग्रह से निकालने के बाद, पैच के तौर पर लागू किया जाना है. डिफ़ॉल्ट रूप से, यह BaZ-नेटिव पैच लागू करने की सुविधा का इस्तेमाल करता है, जो फ़ज़ मैच और बाइनरी पैच के साथ काम नहीं करता. हालांकि, अगर `patch_tool` एट्रिब्यूट के बारे में बताया गया है या `patch_orgs` एट्रिब्यूट में `-p` के अलावा कोई अन्य आर्ग्युमेंट हैं, तो Baज़र, पैच कमांड लाइन टूल का इस्तेमाल करने लगेगा.
`remote_patch_strip`	पूर्णांक; ज़रूरी नहीं रिमोट पैच में मौजूद फ़ाइल के नाम से हटाए जाने वाले लीडिंग स्लैश की संख्या.
`remote_patches`	शब्दकोश: स्ट्रिंग -> String; ज़रूरी नहीं पैच फ़ाइल के यूआरएल का मैप, इसकी इंटिग्रिटी वैल्यू के लिए. संग्रह को एक्सट्रैक्ट करने और `पैच` एट्रिब्यूट से पैच फ़ाइलों को लागू करने से पहले, इन्हें लागू किया जाता है. यह Baज़ल-नेटिव पैच लागू करने की सुविधा का इस्तेमाल करता है. आपके पास `remote_patch_strip` के साथ पैच स्ट्रिप नंबर को तय करने का विकल्प होता है
`repo_mapping`	शब्दकोश: स्ट्रिंग -> String; आवश्यक लोकल रिपॉज़िटरी के नाम से लेकर ग्लोबल रिपॉज़िटरी के नाम तक का डिक्शनरी. इससे, इस रिपॉज़िटरी की डिपेंडेंसी के लिए फ़ाइल फ़ोल्डर डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है. उदाहरण के लिए, एंट्री `"@foo": "@bar"` से पता चलता है कि किसी भी समय यह रिपॉज़िटरी, `@foo` पर निर्भर करती है. जैसे, `@foo//some:target` पर डिपेंडेंसी. इसे असल में ग्लोबल एलान `@bar` (`@bar//some:target`) में डिपेंडेंसी को हल करना चाहिए.
`sha256`	String; ज़रूरी नहीं डाउनलोड की गई फ़ाइल का अनुमानित SHA-256. यह डाउनलोड की गई फ़ाइल के SHA-256 से मेल खाना चाहिए. _यह एक सुरक्षा जोखिम है SHA-256 को छोड़ने के लिए, क्योंकि रिमोट फ़ाइलें बदल सकती हैं._ इसे छोड़ देना ही सबसे सही फ़ील्ड में आपका बिल्ड नॉन-हर्मेटिक बन जाएगा. डेवलपमेंट करना ज़रूरी नहीं है शिपिंग से पहले, इस एट्रिब्यूट या `इंटिग्रिटी` को सेट किया जाना चाहिए.
`strip_prefix`	String; ज़रूरी नहीं निकाली गई फ़ाइलों से स्ट्रिप करने के लिए एक डायरेक्ट्री प्रीफ़िक्स. कई संग्रह में एक शीर्ष-स्तरीय निर्देशिका होती है जिसमें वह सभी उपयोगी संग्रह में मौजूद फ़ाइलें. इस उपसर्ग को बार-बार तय करने की ज़रूरत नहीं है `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`). अगर तय किया गया प्रीफ़िक्स संग्रह की किसी डायरेक्ट्री का मिलान करते हैं, तो Basel एक गड़बड़ी दिखाएगा.
`type`	String; ज़रूरी नहीं डाउनलोड की गई फ़ाइल के संग्रह का टाइप. डिफ़ॉल्ट रूप से, संग्रह का टाइप, यूआरएल. अगर फ़ाइल का कोई एक्सटेंशन नहीं है, तो आप इसके बाद: `"zip"`, `"jar"`, `"var"`, `"aar"`, `"tar"`, `"tar.gz"`, `"tgz"`, `"tar.xz"`, `"txz"`, `"tar.zst"`, `"tzst"`, `"tar.bz2"`, `"ar"`, या `"deb"`.
`url`	String; ज़रूरी नहीं उस फ़ाइल का यूआरएल जिसे Basel को उपलब्ध कराया जाएगा. यह एक फ़ाइल, http या https यूआरएल होना चाहिए. दूसरे वेबलिंक पर भेजने वाले यूआरएल को भी फ़ॉलो किया जाता है. प्रमाणीकरण समर्थित नहीं है. इस सुविधा का इस्तेमाल करने पर, यूआरएल पैरामीटर को ज़्यादा आसानी से कंट्रोल किया जा सकता है का इस्तेमाल करें.
`urls`	स्ट्रिंग की सूची; ज़रूरी नहीं उस फ़ाइल के यूआरएल की सूची जिसे Basel को उपलब्ध कराया जाएगा. हर एंट्री कोई फ़ाइल, http या https यूआरएल होनी चाहिए. दूसरे वेबलिंक पर भेजने वाले यूआरएल को भी फ़ॉलो किया जाता है. प्रमाणीकरण समर्थित नहीं है. यूआरएल को एक क्रम में तब तक आज़माया जाता है, जब तक कि एक यूआरएल सफल नहीं हो जाता. इसलिए, आपको पहले स्थानीय मिरर की सूची बनानी चाहिए. अगर सभी डाउनलोड फ़ेल हो जाते हैं, तो नियम लागू नहीं होगा.
`workspace_file`	लेबल; ज़रूरी नहीं इस डेटा स्टोर करने की जगह के लिए `वर्कस्पेस` फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. `workspace_file` या `workspace_file_content`, दोनों में से किसी को बताया जा सकता है या दोनों में से कोई भी नहीं बताया जा सकता है.
`workspace_file_content`	String; ज़रूरी नहीं इस डेटा स्टोर करने की जगह के लिए वर्कस्पेस फ़ाइल का कॉन्टेंट. `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` फ़ील्ड की वैल्यू के तौर पर. बेयरर टोकन का इस्तेमाल करके, oauth2 वाले एपीआई पर एचटीटीपी डाउनलोड करने के लिए एट्रिब्यूट और netrc का उदाहरण: 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_path`	String; ज़रूरी नहीं डाउनलोड की गई फ़ाइल के लिए पाथ असाइन किया गया
`executable`	बूलियन; ज़रूरी नहीं क्या डाउनलोड की गई फ़ाइल को एक्ज़ीक्यूटेबल बनाया जाना चाहिए.
`integrity`	String; ज़रूरी नहीं डाउनलोड की गई फ़ाइल के उप-रिसॉर्स इंटेग्रिटी फ़ॉर्मैट में अनुमानित चेकसम. यह डाउनलोड की गई फ़ाइल के चेकसम से मेल खाना चाहिए. _यह एक सुरक्षा जोखिम है चेकसम को छोड़ने के लिए, क्योंकि रिमोट फ़ाइलें बदल सकती हैं._ बेहतर होगा कि आप इसे छोड़ दें फ़ील्ड में आपका बिल्ड नॉन-हर्मेटिक बन जाएगा. डेवलपमेंट करना ज़रूरी नहीं है लेकिन शिपिंग से पहले इस एट्रिब्यूट या `sha256` को सेट किया जाना चाहिए.
`netrc`	String; ज़रूरी नहीं पुष्टि करने के लिए .netrc फ़ाइल की जगह
`repo_mapping`	शब्दकोश: स्ट्रिंग -> String; आवश्यक लोकल रिपॉज़िटरी के नाम से लेकर ग्लोबल रिपॉज़िटरी के नाम तक का डिक्शनरी. इससे, इस रिपॉज़िटरी की डिपेंडेंसी के लिए फ़ाइल फ़ोल्डर डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है. उदाहरण के लिए, एंट्री `"@foo": "@bar"` से पता चलता है कि किसी भी समय यह रिपॉज़िटरी, `@foo` पर निर्भर करती है. जैसे, `@foo//some:target` पर डिपेंडेंसी. इसे असल में ग्लोबल एलान `@bar` (`@bar//some:target`) में डिपेंडेंसी को हल करना चाहिए.
`sha256`	String; ज़रूरी नहीं डाउनलोड की गई फ़ाइल का अनुमानित SHA-256. यह डाउनलोड की गई फ़ाइल के SHA-256 से मेल खाना चाहिए. _यह एक सुरक्षा जोखिम है SHA-256 को छोड़ने के लिए, क्योंकि रिमोट फ़ाइलें बदल सकती हैं._ इसे छोड़ देना ही सबसे सही फ़ील्ड में आपका बिल्ड नॉन-हर्मेटिक बन जाएगा. डेवलपमेंट करना ज़रूरी नहीं है आसान है, लेकिन इसे शिपिंग से पहले सेट किया जाना चाहिए.
`url`	String; ज़रूरी नहीं उस फ़ाइल का यूआरएल जिसे Basel को उपलब्ध कराया जाएगा. यह एक फ़ाइल, http या https यूआरएल होना चाहिए. दूसरे वेबलिंक पर भेजने वाले यूआरएल को भी फ़ॉलो किया जाता है. प्रमाणीकरण समर्थित नहीं है. इस सुविधा का इस्तेमाल करने पर, यूआरएल पैरामीटर को ज़्यादा आसानी से कंट्रोल किया जा सकता है का इस्तेमाल करें.
`urls`	स्ट्रिंग की सूची; ज़रूरी नहीं उस फ़ाइल के यूआरएल की सूची जिसे Basel को उपलब्ध कराया जाएगा. हर एंट्री कोई फ़ाइल, http या https यूआरएल होनी चाहिए. दूसरे वेबलिंक पर भेजने वाले यूआरएल को भी फ़ॉलो किया जाता है. प्रमाणीकरण समर्थित नहीं है. यूआरएल को एक क्रम में तब तक आज़माया जाता है, जब तक कि एक यूआरएल सफल नहीं हो जाता. इसलिए, आपको पहले स्थानीय मिरर की सूची बनानी चाहिए. अगर सभी डाउनलोड फ़ेल हो जाते हैं, तो नियम लागू नहीं होगा.

http_jar

http_jar(name, auth_patterns, canonical_id, downloaded_file_name, integrity, netrc, repo_mapping,
         sha256, url, urls)

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

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

उदाहरणः मान लीजिए कि मौजूदा रिपॉज़िटरी में ऐसे चैट प्रोग्राम का सोर्स कोड है जो डायरेक्ट्री ~/chat-app. यह एक ऐसी SSL लाइब्रेरी पर निर्भर होना चाहिए, जो 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 को डिपेंडेंसी के तौर पर तय करेगा.

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

विशेषताएं

`name`	नाम; आवश्यक डेटा स्टोर करने की इस जगह के लिए यूनीक नाम.
`auth_patterns`	शब्दकोश: स्ट्रिंग -> String; ज़रूरी नहीं यह एक ऐसा लिखवाने की सुविधा है जो होस्ट के नामों को कस्टम ऑथराइज़ेशन पैटर्न के साथ मैप करती है. अगर इस डिक्शनरी में किसी यूआरएल का होस्ट का नाम मौजूद है, तो वैल्यू को पैटर्न के तौर पर तब इस्तेमाल किया जाएगा, जब एचटीटीपी अनुरोध के लिए, ऑथराइज़ेशन हेडर जनरेट करना. इससे कस्टम कस्टम पैरामीटर अनुमति देने वाली स्कीम का इस्तेमाल, क्लाउड स्टोरेज उपलब्ध कराने वाली ज़्यादातर सामान्य कंपनियों में किया जाता है. फ़िलहाल, पैटर्न में दो टोकन इस्तेमाल किए जा सकते हैं: `<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`	String; ज़रूरी नहीं डाउनलोड की गई फ़ाइल का कैननिकल आईडी. अगर बताया गया है और खाली नहीं है, तो Baज़र, कैश मेमोरी से फ़ाइल नहीं लेगा, जब तक कि वह कैश मेमोरी में, उसी कैननिकल आईडी वाले अनुरोध से जोड़ा गया था. अगर यह बताया नहीं जाता या खाली होता है, तो Baज़र, डिफ़ॉल्ट रूप से फ़ाइल के यूआरएल को इस तरह इस्तेमाल करता है: कैननिकल आईडी होना चाहिए. इससे यूआरएल को अपडेट किए बिना, आम तौर पर होने वाली गलती का पता लगाने में मदद मिलती है साथ ही, हैश को अपडेट भी करता है. इससे ऐसे बिल्ड मिलते हैं जो लोकल तौर पर काम करते हैं, लेकिन बिना कैश मेमोरी वाली फ़ाइल नहीं है. इस व्यवहार को इससे बंद किया जा सकता है: --repo_env=BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID=0.
`downloaded_file_name`	String; ज़रूरी नहीं जार को असाइन की गई फ़ाइल का नाम डाउनलोड किया गया
`integrity`	String; ज़रूरी नहीं डाउनलोड की गई फ़ाइल के उप-रिसॉर्स इंटेग्रिटी फ़ॉर्मैट में अनुमानित चेकसम. यह डाउनलोड की गई फ़ाइल के चेकसम से मेल खाना चाहिए. _यह एक सुरक्षा जोखिम है चेकसम को छोड़ने के लिए, क्योंकि रिमोट फ़ाइलें बदल सकती हैं._ बेहतर होगा कि आप इसे छोड़ दें फ़ील्ड में आपका बिल्ड नॉन-हर्मेटिक बन जाएगा. डेवलपमेंट करना ज़रूरी नहीं है लेकिन शिपिंग से पहले इस एट्रिब्यूट या `sha256` को सेट किया जाना चाहिए.
`netrc`	String; ज़रूरी नहीं पुष्टि करने के लिए .netrc फ़ाइल की जगह
`repo_mapping`	शब्दकोश: स्ट्रिंग -> String; आवश्यक लोकल रिपॉज़िटरी के नाम से लेकर ग्लोबल रिपॉज़िटरी के नाम तक का डिक्शनरी. इससे, इस रिपॉज़िटरी की डिपेंडेंसी के लिए फ़ाइल फ़ोल्डर डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है. उदाहरण के लिए, एंट्री `"@foo": "@bar"` से पता चलता है कि किसी भी समय यह रिपॉज़िटरी, `@foo` पर निर्भर करती है. जैसे, `@foo//some:target` पर डिपेंडेंसी. इसे असल में ग्लोबल एलान `@bar` (`@bar//some:target`) में डिपेंडेंसी को हल करना चाहिए.
`sha256`	String; ज़रूरी नहीं डाउनलोड की गई फ़ाइल का अनुमानित SHA-256. यह डाउनलोड की गई फ़ाइल के SHA-256 से मेल खाना चाहिए. _यह एक सुरक्षा जोखिम है SHA-256 को छोड़ने के लिए, क्योंकि रिमोट फ़ाइलें बदल सकती हैं._ इसे छोड़ देना ही सबसे सही फ़ील्ड में आपका बिल्ड नॉन-हर्मेटिक बन जाएगा. डेवलपमेंट करना ज़रूरी नहीं है शिपिंग से पहले, इस एट्रिब्यूट या `इंटिग्रिटी` को सेट किया जाना चाहिए.
`url`	String; ज़रूरी नहीं उस फ़ाइल का यूआरएल जिसे Basel को उपलब्ध कराया जाएगा. यह एक फ़ाइल, http या https यूआरएल होना चाहिए. दूसरे वेबलिंक पर भेजने वाले यूआरएल को भी फ़ॉलो किया जाता है. प्रमाणीकरण समर्थित नहीं है. इस सुविधा का इस्तेमाल करने पर, यूआरएल पैरामीटर को ज़्यादा आसानी से कंट्रोल किया जा सकता है का इस्तेमाल करें. यूआरएल के आखिर में `.Jar` होना चाहिए.
`urls`	स्ट्रिंग की सूची; ज़रूरी नहीं उस फ़ाइल के यूआरएल की सूची जिसे Basel को उपलब्ध कराया जाएगा. हर एंट्री कोई फ़ाइल, http या https यूआरएल होनी चाहिए. दूसरे वेबलिंक पर भेजने वाले यूआरएल को भी फ़ॉलो किया जाता है. प्रमाणीकरण समर्थित नहीं है. यूआरएल को एक क्रम में तब तक आज़माया जाता है, जब तक कि एक यूआरएल सफल नहीं हो जाता. इसलिए, आपको पहले स्थानीय मिरर की सूची बनानी चाहिए. अगर सभी डाउनलोड फ़ेल हो जाते हैं, तो नियम लागू नहीं होगा. सभी यूआरएल के आखिर में `.jar` होना चाहिए.