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

समस्या की शिकायत करें सोर्स देखें

Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

इन फ़ंक्शन को @bazel_tools//tools/build_defs/repo:http.bzl से लोड किया जा सकता है.

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, 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, संग्रह को कैश मेमोरी से नहीं लेगा. हालांकि, ऐसा तब किया जाएगा, जब इसे एक ही कैननिकल आईडी वाले अनुरोध से कैश मेमोरी में जोड़ा गया हो.
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_patch_strip	पूर्णांक; ज़रूरी नहीं रिमोट पैच में फ़ाइल के नाम से हटाए जाने वाले शुरुआती स्लैश की संख्या.
remote_patches	डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी नहीं यह पैच फ़ाइल के यूआरएल और उसकी इंटिग्रिटी वैल्यू का मैप होता है. इन्हें संग्रह को निकालने के बाद और `patches` एट्रिब्यूट से पैच फ़ाइलें लागू करने से पहले लागू किया जाता है. यह Bazel के नेटिव पैच को लागू करने की सुविधा का इस्तेमाल करता है. `remote_patch_strip` की मदद से, पैच स्ट्रिप नंबर तय किया जा सकता है
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,
          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, संग्रह को कैश मेमोरी से नहीं लेगा. हालांकि, ऐसा तब किया जाएगा, जब इसे एक ही कैननिकल आईडी वाले अनुरोध से कैश मेमोरी में जोड़ा गया हो.
downloaded_file_path	स्ट्रिंग; ज़रूरी नहीं डाउनलोड की गई फ़ाइल को असाइन किया गया पाथ
executable	बूलियन; ज़रूरी नहीं अगर डाउनलोड की गई फ़ाइल को एक्ज़ीक्यूटेबल बनाया जाना चाहिए.
integrity	स्ट्रिंग; ज़रूरी नहीं डाउनलोड की गई फ़ाइल का, सबरिसॉर्स इंटिग्रिटी फ़ॉर्मैट में अनुमानित चेकसम. यह डाउनलोड की गई फ़ाइल के चेकसम से मेल खाना चाहिए. _चेकसाम को शामिल न करने से सुरक्षा से जुड़ी समस्या हो सकती है, क्योंकि रिमोट फ़ाइलें बदल सकती हैं._ इस फ़ील्ड को शामिल न करने से, आपका बिल्ड नॉन-हर्मेटिक हो जाएगा. इससे डेवलपमेंट को आसान बनाने में मदद मिलती है. हालांकि, शिपिंग से पहले इस एट्रिब्यूट या `sha256` में से किसी एक को सेट करना ज़रूरी है.
netrc	स्ट्रिंग; ज़रूरी नहीं पुष्टि के लिए इस्तेमाल की जाने वाली .netrc फ़ाइल की जगह
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, 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",
  )

टारगेट, इस जार पर निर्भर रहने के लिए <code>@my_ssl//jar</code> को डिपेंडेंसी के तौर पर तय करेंगे.

अगर 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, संग्रह को कैश मेमोरी से नहीं लेगा. हालांकि, ऐसा तब किया जाएगा, जब इसे एक ही कैननिकल आईडी वाले अनुरोध से कैश मेमोरी में जोड़ा गया हो.
downloaded_file_name	स्ट्रिंग; ज़रूरी नहीं डाउनलोड किए गए जार को असाइन किया गया फ़ाइल का नाम
integrity	स्ट्रिंग; ज़रूरी नहीं डाउनलोड की गई फ़ाइल का, सबरिसॉर्स इंटिग्रिटी फ़ॉर्मैट में अनुमानित चेकसम. यह डाउनलोड की गई फ़ाइल के चेकसम से मेल खाना चाहिए. _चेकसाम को शामिल न करने से सुरक्षा से जुड़ी समस्या हो सकती है, क्योंकि रिमोट फ़ाइलें बदल सकती हैं._ इस फ़ील्ड को शामिल न करने से, आपका बिल्ड नॉन-हर्मेटिक हो जाएगा. इससे डेवलपमेंट को आसान बनाने में मदद मिलती है. हालांकि, शिपिंग से पहले इस एट्रिब्यूट या `sha256` में से किसी एक को सेट करना ज़रूरी है.
netrc	स्ट्रिंग; ज़रूरी नहीं पुष्टि के लिए इस्तेमाल की जाने वाली .netrc फ़ाइल की जगह
sha256	स्ट्रिंग; ज़रूरी नहीं डाउनलोड की गई फ़ाइल का SHA-256 हैश. यह, डाउनलोड की गई फ़ाइल के SHA-256 से मेल खाना चाहिए. _SHA-256 को शामिल न करने से सुरक्षा से जुड़ी समस्या हो सकती है, क्योंकि रिमोट फ़ाइलें बदल सकती हैं._ इस फ़ील्ड को शामिल न करने से, आपका बिल्ड हर्मेटिक नहीं रहेगा. इससे डेवलपमेंट को आसान बनाने में मदद मिलती है. हालांकि, शिपिंग से पहले इस एट्रिब्यूट या `integrity` को सेट करना ज़रूरी है.
url	स्ट्रिंग; ज़रूरी नहीं उस फ़ाइल का यूआरएल जिसे Bazel के लिए उपलब्ध कराया जाएगा. यह एक फ़ाइल, http या https यूआरएल होना चाहिए. रीडायरेक्ट किए गए यूआरएल को इसमें शामिल किया जाता है. पुष्टि करने की सुविधा काम नहीं करती. urls पैरामीटर की मदद से, ज़्यादा फ़्लेक्सिबिलिटी हासिल की जा सकती है. इसकी मदद से, फ़ेच करने के लिए वैकल्पिक यूआरएल तय किए जा सकते हैं. यूआरएल `.jar` पर खत्म होना चाहिए.
urls	स्ट्रिंग की सूची; ज़रूरी नहीं यह एक ऐसी फ़ाइल के यूआरएल की सूची होती है जिसे Bazel के लिए उपलब्ध कराया जाएगा. हर एंट्री, कोई फ़ाइल, http या https यूआरएल होना चाहिए. रीडायरेक्ट किए गए यूआरएल को इसमें शामिल किया जाता है. पुष्टि करने की सुविधा काम नहीं करती. जब तक कोई यूआरएल काम नहीं करता, तब तक यूआरएल को क्रम से आज़माया जाता है. इसलिए, आपको सबसे पहले लोकल मिरर की सूची बनानी चाहिए. अगर सभी डाउनलोड पूरे नहीं होते हैं, तो नियम लागू नहीं होगा. सभी यूआरएल `.jar` पर खत्म होने चाहिए.