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

इन फ़ंक्शन को @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 Dictionary: String -> String; optional

यह एक डिक्शनरी है, जिसमें होस्ट के नाम को कस्टम ऑथराइज़ेशन पैटर्न पर मैप किया जाता है. हालांकि, ऐसा करना ज़रूरी नहीं है. अगर किसी यूआरएल के होस्ट का नाम इस डिक्शनरी में मौजूद है, तो वैल्यू का इस्तेमाल पैटर्न के तौर पर किया जाएगा. ऐसा तब होगा, जब एचटीटीपी अनुरोध के लिए अनुमति देने वाला हेडर जनरेट किया जा रहा हो. इससे, क्लाउड स्टोरेज उपलब्ध कराने वाली कई कंपनियों के कस्टम ऑथराइज़ेशन स्कीम का इस्तेमाल किया जा सकता है. फ़िलहाल, पैटर्न में दो टोकन इस्तेमाल किए जा सकते हैं: <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, संग्रह को कैश मेमोरी से लेगा.

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 Dictionary: String -> String; optional

यह पैच फ़ाइल के यूआरएल को उसकी इंटिग्रिटी वैल्यू से मैप करता है. इन्हें संग्रह को निकालने के बाद और `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 स्ट्रिंग की सूची; ज़रूरी नहीं

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 पर उपलब्ध है. इसके बाद, अपने फ़ाइल फ़ोल्डर में ये फ़ाइलें जोड़ी जा सकती हैं:

  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 Dictionary: String -> String; optional

यह एक डिक्शनरी है, जिसमें होस्ट के नाम को कस्टम ऑथराइज़ेशन पैटर्न पर मैप किया जाता है. हालांकि, ऐसा करना ज़रूरी नहीं है. अगर किसी यूआरएल के होस्ट का नाम इस डिक्शनरी में मौजूद है, तो वैल्यू का इस्तेमाल पैटर्न के तौर पर किया जाएगा. ऐसा तब होगा, जब एचटीटीपी अनुरोध के लिए अनुमति देने वाला हेडर जनरेट किया जा रहा हो. इससे, क्लाउड स्टोरेज उपलब्ध कराने वाली कई कंपनियों के कस्टम ऑथराइज़ेशन स्कीम का इस्तेमाल किया जा सकता है. फ़िलहाल, पैटर्न में दो टोकन इस्तेमाल किए जा सकते हैं: <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, संग्रह को कैश मेमोरी से लेगा.

downloaded_file_path स्ट्रिंग; ज़रूरी नहीं

डाउनलोड की गई फ़ाइल को असाइन किया गया पाथ

executable बूलियन; ज़रूरी नहीं

अगर डाउनलोड की गई फ़ाइल को एक्ज़ीक्यूटेबल बनाना है.

integrity स्ट्रिंग; ज़रूरी नहीं

डाउनलोड की गई फ़ाइल का, सबरिसॉर्स इंटिग्रिटी फ़ॉर्मैट में अनुमानित चेकसम. यह डाउनलोड की गई फ़ाइल के चेकसम से मेल खाना चाहिए. _चेकसम को शामिल न करने से सुरक्षा से जुड़ी समस्या हो सकती है, क्योंकि रिमोट फ़ाइलें बदल सकती हैं._ इस फ़ील्ड को शामिल न करने से, आपका बिल्ड नॉन-हर्मेटिक हो जाएगा. इससे डेवलपमेंट को आसान बनाने में मदद मिलती है. हालांकि, शिपिंग से पहले इस एट्रिब्यूट या `sha256` में से किसी एक को सेट करना ज़रूरी है.

netrc स्ट्रिंग; ज़रूरी नहीं

पुष्टि के लिए इस्तेमाल की जाने वाली .netrc फ़ाइल की जगह

sha256 स्ट्रिंग; ज़रूरी नहीं

डाउनलोड की गई फ़ाइल का SHA-256 हैश. यह, डाउनलोड की गई फ़ाइल के SHA-256 से मेल खाना चाहिए. _SHA-256 को शामिल न करने से सुरक्षा से जुड़ी समस्या हो सकती है, क्योंकि रिमोट फ़ाइलें बदल सकती हैं._ इस फ़ील्ड को शामिल न करने से, आपका बिल्ड नॉन-हर्मेटिक हो जाएगा. इससे डेवलपमेंट को आसान बनाने में मदद मिलती है. हालांकि, इसे शिपिंग से पहले सेट करना ज़रूरी है.

url स्ट्रिंग; ज़रूरी नहीं

उस फ़ाइल का यूआरएल जिसे Bazel के लिए उपलब्ध कराया जाएगा. यह एक फ़ाइल, http या https यूआरएल होना चाहिए. रीडायरेक्ट किए गए यूआरएल को इसमें शामिल किया जाता है. पुष्टि करने की सुविधा काम नहीं करती. यूआरएल पैरामीटर की मदद से, ज़्यादा फ़्लेक्सिबिलिटी हासिल की जा सकती है. इसकी मदद से, फ़ेच करने के लिए वैकल्पिक यूआरएल तय किए जा सकते हैं.

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/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",
  )

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

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

विशेषताएं

name नाम; ज़रूरी है

इस डेटाबेस के लिए यूनीक नाम.

auth_patterns Dictionary: String -> String; optional

यह एक डिक्शनरी है, जिसमें होस्ट के नाम को कस्टम ऑथराइज़ेशन पैटर्न पर मैप किया जाता है. हालांकि, ऐसा करना ज़रूरी नहीं है. अगर किसी यूआरएल के होस्ट का नाम इस डिक्शनरी में मौजूद है, तो वैल्यू का इस्तेमाल पैटर्न के तौर पर किया जाएगा. ऐसा तब होगा, जब एचटीटीपी अनुरोध के लिए अनुमति देने वाला हेडर जनरेट किया जा रहा हो. इससे, क्लाउड स्टोरेज उपलब्ध कराने वाली कई कंपनियों के कस्टम ऑथराइज़ेशन स्कीम का इस्तेमाल किया जा सकता है. फ़िलहाल, पैटर्न में दो टोकन इस्तेमाल किए जा सकते हैं: <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, संग्रह को कैश मेमोरी से लेगा.

downloaded_file_name स्ट्रिंग; ज़रूरी नहीं

डाउनलोड किए गए जार को असाइन किया गया फ़ाइल का नाम

integrity स्ट्रिंग; ज़रूरी नहीं

डाउनलोड की गई फ़ाइल का, सबरिसॉर्स इंटिग्रिटी फ़ॉर्मैट में अनुमानित चेकसम. यह डाउनलोड की गई फ़ाइल के चेकसम से मेल खाना चाहिए. _चेकसम को शामिल न करने से सुरक्षा से जुड़ी समस्या हो सकती है, क्योंकि रिमोट फ़ाइलें बदल सकती हैं._ इस फ़ील्ड को शामिल न करने से, आपका बिल्ड नॉन-हर्मेटिक हो जाएगा. इससे डेवलपमेंट को आसान बनाने में मदद मिलती है. हालांकि, शिपिंग से पहले इस एट्रिब्यूट या `sha256` में से किसी एक को सेट करना ज़रूरी है.

netrc स्ट्रिंग; ज़रूरी नहीं

पुष्टि के लिए इस्तेमाल की जाने वाली .netrc फ़ाइल की जगह

sha256 स्ट्रिंग; ज़रूरी नहीं

डाउनलोड की गई फ़ाइल का SHA-256 हैश. यह, डाउनलोड की गई फ़ाइल के SHA-256 से मेल खाना चाहिए. _SHA-256 को शामिल न करने से सुरक्षा से जुड़ी समस्या हो सकती है, क्योंकि रिमोट फ़ाइलें बदल सकती हैं._ इस फ़ील्ड को शामिल न करने से, आपका बिल्ड नॉन-हर्मेटिक हो जाएगा. इससे डेवलपमेंट आसान हो जाता है. हालांकि, शिपिंग से पहले इस एट्रिब्यूट या `integrity` को सेट करना ज़रूरी है.

url स्ट्रिंग; ज़रूरी नहीं

उस फ़ाइल का यूआरएल जिसे Bazel के लिए उपलब्ध कराया जाएगा. यह एक फ़ाइल, http या https यूआरएल होना चाहिए. रीडायरेक्ट किए गए यूआरएल को इसमें शामिल किया जाता है. पुष्टि करने की सुविधा काम नहीं करती. यूआरएल पैरामीटर की मदद से, ज़्यादा फ़्लेक्सिबिलिटी हासिल की जा सकती है. इसकी मदद से, फ़ेच करने के लिए वैकल्पिक यूआरएल तय किए जा सकते हैं. यूआरएल `.jar` पर खत्म होना चाहिए.

urls स्ट्रिंग की सूची; ज़रूरी नहीं

Bazel को उपलब्ध कराई जाने वाली फ़ाइल के यूआरएल की सूची. हर एंट्री एक फ़ाइल, http या https यूआरएल होनी चाहिए. रीडायरेक्ट किए गए यूआरएल को इसमें शामिल किया जाता है. पुष्टि करने की सुविधा काम नहीं करती. जब तक कोई यूआरएल काम नहीं करता, तब तक यूआरएल को क्रम से आज़माया जाता है. इसलिए, आपको सबसे पहले लोकल मिरर की सूची बनानी चाहिए. अगर सभी डाउनलोड पूरे नहीं होते हैं, तो नियम लागू नहीं होगा. सभी यूआरएल `.jar` पर खत्म होने चाहिए.