इस पेज का अनुवाद 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)

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

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