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

समस्या की शिकायत करें सोर्स देखें Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

इन फ़ंक्शन को @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_file_integrity, remote_file_urls, 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`	डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी नहीं यह एक डिक्शनरी है, जिसमें होस्टनेम को कस्टम ऑथराइज़ेशन पैटर्न पर मैप किया जाता है. हालांकि, ऐसा करना ज़रूरी नहीं है. अगर किसी यूआरएल का होस्टनेम इस डिक्शनरी में मौजूद है, तो वैल्यू का इस्तेमाल पैटर्न के तौर पर किया जाएगा. ऐसा तब होगा, जब एचटीटीपी अनुरोध के लिए अनुमति देने वाला हेडर जनरेट किया जा रहा हो. इससे, क्लाउड स्टोरेज की सेवाएं देने वाली कई कंपनियों के कस्टम ऑथराइज़ेशन स्कीम का इस्तेमाल किया जा सकता है. फ़िलहाल, पैटर्न में दो टोकन इस्तेमाल किए जा सकते हैं: `<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 फ़ाइलों से अलग करने में मदद मिल सकती है. build_file या build_file_content में से किसी एक को तय किया जा सकता है, लेकिन दोनों को नहीं.
`build_file_content`	स्ट्रिंग; ज़रूरी नहीं इस रिपॉज़िटरी के लिए BUILD फ़ाइल का कॉन्टेंट. build_file या build_file_content में से किसी एक को तय किया जा सकता है, लेकिन दोनों को नहीं.
`canonical_id`	स्ट्रिंग; ज़रूरी नहीं डाउनलोड की गई फ़ाइल का कैननिकल आईडी. अगर यह विकल्प दिया गया है और इसकी वैल्यू खाली नहीं है, तो Bazel फ़ाइल को कैश मेमोरी से नहीं लेगा. ऐसा तब तक होगा, जब तक कि उसे एक ही कैननिकल आईडी वाले अनुरोध से कैश मेमोरी में न जोड़ा गया हो. अगर यह जानकारी नहीं दी गई है या खाली है, तो Bazel डिफ़ॉल्ट रूप से फ़ाइल के यूआरएल को कैननिकल आईडी के तौर पर इस्तेमाल करता है. इससे, यूआरएल को अपडेट करने के दौरान होने वाली आम गलती को ठीक करने में मदद मिलती है. यह गलती तब होती है, जब यूआरएल के साथ-साथ हैश को भी अपडेट नहीं किया जाता. इससे, लोकल मशीन पर तो बिल्ड बन जाते हैं, लेकिन जिन मशीनों में कैश मेमोरी में फ़ाइल मौजूद नहीं होती उन पर बिल्ड नहीं बन पाते. इस सुविधा को बंद करने के लिए, --repo_env=BAZEL_HTTP_RULES_URLS_AS_DEFAULT_CANONICAL_ID=0 का इस्तेमाल करें.
`integrity`	स्ट्रिंग; ज़रूरी नहीं डाउनलोड की गई फ़ाइल का, सबरिसॉर्स इंटिग्रिटी फ़ॉर्मैट में अनुमानित चेकसम. यह डाउनलोड की गई फ़ाइल के चेकसम से मेल खाना चाहिए. _चेकसाम को शामिल न करने से सुरक्षा से जुड़ी समस्या हो सकती है, क्योंकि रिमोट फ़ाइलें बदल सकती हैं._ इस फ़ील्ड को शामिल न करने से, आपका बिल्ड नॉन-हर्मेटिक हो जाएगा. इससे डेवलपमेंट को आसान बनाने में मदद मिलती है. हालांकि, शिपिंग से पहले इस एट्रिब्यूट या `sha256` में से किसी एक को सेट करना ज़रूरी है.
`netrc`	स्ट्रिंग; ज़रूरी नहीं पुष्टि के लिए इस्तेमाल की जाने वाली .netrc फ़ाइल की जगह
`patch_args`	स्ट्रिंग की सूची; ज़रूरी नहीं पैच टूल को दिए गए तर्क. डिफ़ॉल्ट रूप से -p0 पर सेट होता है. हालांकि, git से जनरेट किए गए पैच के लिए आम तौर पर -p1 की ज़रूरत होती है. अगर कई -p आर्ग्युमेंट दिए गए हैं, तो आखिरी आर्ग्युमेंट लागू होगा.अगर -p के अलावा अन्य आर्ग्युमेंट दिए गए हैं, तो Bazel, Bazel-नेटिव पैच लागू करने के बजाय, पैच कमांड लाइन टूल का इस्तेमाल करेगा. जब पैच कमांड लाइन टूल पर वापस आ रहे हों और patch_tool एट्रिब्यूट की वैल्यू नहीं दी गई हो, तब `patch` का इस्तेमाल किया जाएगा. इससे सिर्फ़ `patches` एट्रिब्यूट में मौजूद पैच फ़ाइलों पर असर पड़ता है.
`patch_cmds`	स्ट्रिंग की सूची; ज़रूरी नहीं पैच लागू होने के बाद, Linux/macOS पर लागू की जाने वाली Bash कमांड का क्रम.
`patch_cmds_win`	स्ट्रिंग की सूची; ज़रूरी नहीं पैच लागू होने के बाद, Windows पर लागू की जाने वाली Powershell कमांड का क्रम. अगर इस एट्रिब्यूट को सेट नहीं किया जाता है, तो Windows पर patch_cmds को एक्ज़ीक्यूट किया जाएगा. इसके लिए, Bash बाइनरी का मौजूद होना ज़रूरी है.
`patch_tool`	स्ट्रिंग; ज़रूरी नहीं इस्तेमाल की जाने वाली पैच(1) यूटिलिटी. अगर इसे तय किया जाता है, तो Bazel, Bazel के नेटिव पैच लागू करने के बजाय, तय किए गए पैच टूल का इस्तेमाल करेगा.
`patches`	लेबल की सूची; ज़रूरी नहीं यह उन फ़ाइलों की सूची है जिन्हें संग्रह को निकालने के बाद पैच के तौर पर लागू किया जाना है. डिफ़ॉल्ट रूप से, यह Bazel-native पैच लागू करने की सुविधा का इस्तेमाल करता है. यह सुविधा, फ़ज़ मैच और बाइनरी पैच के साथ काम नहीं करती. हालांकि, अगर `patch_tool` एट्रिब्यूट की जानकारी दी गई है या `patch_args` एट्रिब्यूट में `-p` के अलावा अन्य आर्ग्युमेंट मौजूद हैं, तो Bazel, पैच कमांड लाइन टूल का इस्तेमाल करेगा.
`remote_file_integrity`	डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी नहीं यह फ़ाइल के रिलेटिव पाथ (कुंजी) से लेकर उसकी इंटिग्रिटी वैल्यू (वैल्यू) तक का मैप होता है. ये रिलेटिव पाथ, `remote_file_urls` एट्रिब्यूट में मौजूद फ़ाइलों (कुंजी) से मैप होने चाहिए.
`remote_file_urls`	डिक्शनरी: स्ट्रिंग -> स्ट्रिंग की सूची; ज़रूरी नहीं यह रिलेटिव पाथ (कुंजी) के मैप से यूआरएल (वैल्यू) की सूची बनाता है. इन यूआरएल को डाउनलोड किया जाता है और रिपॉज़िटरी में ओवरले की गई फ़ाइलों के तौर पर उपलब्ध कराया जाता है. यह तब काम आता है, जब आपको किसी मौजूदा रिपॉज़िटरी में WORKSPACE या BUILD.bazel फ़ाइलें जोड़नी हों. `patches` एट्रिब्यूट में पैच लागू करने से पहले, फ़ाइलें डाउनलोड की जाती हैं. साथ ही, यूआरएल की सूची में एक ही फ़ाइल के सभी संभावित मिरर होने चाहिए. जब तक कोई यूआरएल काम नहीं करता, तब तक यूआरएल को क्रम से आज़माया जाता है.
`remote_patch_strip`	पूर्णांक; ज़रूरी नहीं रिमोट पैच में फ़ाइल के नाम से हटाए जाने वाले शुरुआती स्लैश की संख्या.
`remote_patches`	डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी नहीं यह पैच फ़ाइल के यूआरएल और उसकी इंटिग्रिटी वैल्यू का मैप होता है. इन्हें संग्रह को निकालने के बाद और `patches` एट्रिब्यूट से पैच फ़ाइलें लागू करने से पहले लागू किया जाता है. यह Bazel के नेटिव पैच को लागू करने की सुविधा का इस्तेमाल करता है. `remote_patch_strip` की मदद से, पैच स्ट्रिप नंबर तय किया जा सकता है
`repo_mapping`	Dictionary: String -> String; ज़रूरी है लोकल रिपॉज़िटरी के नाम से ग्लोबल रिपॉज़िटरी के नाम तक की डिक्शनरी. इससे इस रिपॉज़िटरी की डिपेंडेंसी के लिए, वर्कस्पेस डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है. उदाहरण के लिए, `"@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`). अगर दिया गया प्रीफ़िक्स, संग्रह में मौजूद किसी डायरेक्ट्री से मेल नहीं खाता है, तो 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` फ़ील्ड की वैल्यू के तौर पर सेट किया जाता है. बेयरर टोकन का इस्तेमाल करके, OAuth2 की सुविधा वाले एपीआई से एचटीटीपी डाउनलोड करने के लिए, एट्रिब्यूट और netrc का उदाहरण: 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_RULES_URLS_AS_DEFAULT_CANONICAL_ID=0 का इस्तेमाल करें.
`downloaded_file_path`	स्ट्रिंग; ज़रूरी नहीं डाउनलोड की गई फ़ाइल को असाइन किया गया पाथ
`executable`	बूलियन; ज़रूरी नहीं अगर डाउनलोड की गई फ़ाइल को एक्ज़ीक्यूटेबल बनाया जाना चाहिए.
`integrity`	स्ट्रिंग; ज़रूरी नहीं डाउनलोड की गई फ़ाइल का, सबरिसॉर्स इंटिग्रिटी फ़ॉर्मैट में अनुमानित चेकसम. यह डाउनलोड की गई फ़ाइल के चेकसम से मेल खाना चाहिए. _चेकसाम को शामिल न करने से सुरक्षा से जुड़ी समस्या हो सकती है, क्योंकि रिमोट फ़ाइलें बदल सकती हैं._ इस फ़ील्ड को शामिल न करने से, आपका बिल्ड नॉन-हर्मेटिक हो जाएगा. इससे डेवलपमेंट को आसान बनाने में मदद मिलती है. हालांकि, शिपिंग से पहले इस एट्रिब्यूट या `sha256` में से किसी एक को सेट करना ज़रूरी है.
`netrc`	स्ट्रिंग; ज़रूरी नहीं पुष्टि के लिए इस्तेमाल की जाने वाली .netrc फ़ाइल की जगह
`repo_mapping`	Dictionary: String -> String; ज़रूरी है लोकल रिपॉज़िटरी के नाम से ग्लोबल रिपॉज़िटरी के नाम तक की डिक्शनरी. इससे इस रिपॉज़िटरी की डिपेंडेंसी के लिए, वर्कस्पेस डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है. उदाहरण के लिए, `"@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)

यह फ़ंक्शन, किसी यूआरएल से जार डाउनलोड करता है और उसे java_import के तौर पर उपलब्ध कराता है

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

उदाहरण: मान लें कि मौजूदा रिपॉज़िटरी में, चैट प्रोग्राम का सोर्स कोड है. यह ~/chat-app डायरेक्ट्री में मौजूद है. यह http://example.com/openssl-0.2.jar से उपलब्ध एसएसएल लाइब्रेरी पर निर्भर होना चाहिए.

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