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

7.3 · 7.2 · 7.1 · 7.0 · 6.5

ये फ़ंक्शन, @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 रिपॉज़िटरी में मौजूद टारगेट, इस टारगेट पर निर्भर हो सकते हैं. इसके लिए, ~/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` (अगर कोई है) लागू करने के बाद, संग्रह को इस डायरेक्ट्री में अनपैक किया जाएगा. उदाहरण के लिए, अगर `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>" } नेटवर्क: 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`	स्ट्रिंग; वैकल्पिक डाउनलोड किए गए संग्रह का कैननिकल आईडी. अगर बताया गया है और खाली नहीं है, तो बेज़ल कैश मेमोरी से संग्रह नहीं लेगा, जब तक कि इसे उसी कैननिकल आईडी वाले अनुरोध के ज़रिए कैश मेमोरी में नहीं जोड़ा गया हो.
`integrity`	स्ट्रिंग; वैकल्पिक डाउनलोड की गई फ़ाइल के सब-सोर्स इंटिग्रिटी फ़ॉर्मैट में, उम्मीद के मुताबिक चेकसम. यह डाउनलोड की गई फ़ाइल के चेकसम से मेल खाना चाहिए. _चेकसम को शामिल न करना सुरक्षा के लिहाज़ से जोखिम भरा है, क्योंकि रिमोट फ़ाइलों में बदलाव हो सकता है._ इस फ़ील्ड को शामिल न करने पर, आपका बिल्ड पूरी तरह से सुरक्षित नहीं रहेगा. डेवलपमेंट को आसान बनाना ज़रूरी नहीं है. हालांकि, शिपिंग से पहले इस एट्रिब्यूट या `sha256` को सेट करना ज़रूरी है.
`netrc`	स्ट्रिंग; वैकल्पिक पुष्टि करने के लिए इस्तेमाल की जाने वाली .netrc फ़ाइल की जगह
`patch_args`	स्ट्रिंग की सूची; वैकल्पिक पैच टूल को दिए गए आर्ग्युमेंट. डिफ़ॉल्ट रूप से -p0 पर सेट होता है. हालांकि, git से जनरेट किए गए पैच के लिए आम तौर पर -p1 की ज़रूरत होगी. अगर एक से ज़्यादा -p आर्ग्युमेंट दिए जाते हैं, तो आखिरी आर्ग्युमेंट लागू होगा. अगर -p के अलावा कोई अन्य आर्ग्युमेंट दिया जाता है, तो Bazel, Bazel-नेटिव पैच लागू करने के बजाय, पैच कमांड लाइन टूल का इस्तेमाल करेगा. अगर पैच कमांड लाइन टूल का इस्तेमाल किया जा रहा है और patch_tool एट्रिब्यूट की वैल्यू नहीं दी गई है, तो `patch` का इस्तेमाल किया जाएगा. इससे सिर्फ़ `पैच` एट्रिब्यूट में मौजूद पैच फ़ाइलों पर असर पड़ता है.
`patch_cmds`	स्ट्रिंग की सूची; वैकल्पिक पैच लागू होने के बाद, Linux/Macos पर लागू किए जाने वाले Bash कमांड का क्रम.
`patch_cmds_win`	स्ट्रिंग की सूची; ज़रूरी नहीं पैच लागू होने के बाद, Windows पर लागू किए जाने वाले Powershell निर्देशों का क्रम. अगर यह एट्रिब्यूट सेट नहीं है, तो patch_cmds को Windows पर चलाया जाएगा. इसके लिए, Bash बाइनरी मौजूद होनी चाहिए.
`patch_tool`	स्ट्रिंग; ज़रूरी नहीं इस्तेमाल की जाने वाली पैच(1) सुविधा. अगर इसका इस्तेमाल किया जा रहा है, तो Basel-नेटिव पैच को लागू करने के बजाय, Basel के बताए गए पैच टूल का इस्तेमाल किया जाएगा.
`patches`	लेबल की सूची; ज़रूरी नहीं उन फ़ाइलों की सूची जिन्हें संग्रह को निकालने के बाद, पैच के तौर पर लागू करना है. डिफ़ॉल्ट रूप से, यह Baज़ल-नेटिव पैच लागू करने की सुविधा का इस्तेमाल करता है, जो फ़ज़ मैच और बाइनरी पैच के साथ काम नहीं करता. हालांकि, अगर `patch_tool` एट्रिब्यूट के बारे में बताया गया है या `patch_orgs` एट्रिब्यूट में `-p` के अलावा कोई अन्य आर्ग्युमेंट हैं, तो Baज़र, पैच कमांड लाइन टूल का इस्तेमाल करने लगेगा.
`remote_patch_strip`	पूर्णांक; ज़रूरी नहीं रिमोट पैच में, फ़ाइल के नाम से हटाए जाने वाले शुरुआती स्लैश की संख्या.
`remote_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`, `"txz``, `"tar.zst`2`, `"txz``, `"tar.zst`2`.
`url`	स्ट्रिंग; ज़रूरी नहीं उस फ़ाइल का यूआरएल, जिसे Basel को उपलब्ध कराया जाएगा. यह फ़ाइल, http या https यूआरएल होनी चाहिए. दूसरे वेबलिंक पर ले जाने वाले यूआरएल को इसमें शामिल किया जाता है. पुष्टि करने की सुविधा काम नहीं करती. urls पैरामीटर की मदद से ज़्यादा सुविधाएं मिल सकती हैं. इसकी मदद से, फ़ेच करने के लिए वैकल्पिक यूआरएल तय किए जा सकते हैं.
`urls`	स्ट्रिंग की सूची; वैकल्पिक उस फ़ाइल के यूआरएल की सूची जिसे Basel को उपलब्ध कराया जाएगा. हर एंट्री, कोई फ़ाइल, http या https यूआरएल होनी चाहिए. दूसरे वेबलिंक पर भेजने वाले यूआरएल को भी फ़ॉलो किया जाता है. पुष्टि करने की सुविधा काम नहीं करती. यूआरएल को एक क्रम में तब तक आज़माया जाता है, जब तक कि एक यूआरएल को कामयाबी नहीं मिल जाती. इसलिए, आपको पहले स्थानीय मिरर की सूची बनानी चाहिए. अगर सभी डाउनलोड नहीं हो पाते हैं, तो नियम लागू नहीं होगा.
`workspace_file`	लेबल; ज़रूरी नहीं इस रिपॉज़िटरी के लिए, `WORKSPACE` फ़ाइल के तौर पर इस्तेमाल की जाने वाली फ़ाइल. `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,
          sha256, url, urls)

किसी यूआरएल से फ़ाइल डाउनलोड करता है और उसे फ़ाइल ग्रुप के तौर पर इस्तेमाल करने के लिए उपलब्ध कराता है.

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

http_jar

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

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

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

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

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

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

अगर आप यूनिक्स-आधारित सिस्टम का इस्तेमाल कर रहे हैं, तो आप "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>" } नेटवर्क: machine storage.cloudprovider.com password RANDOM-TOKEN आखिरी एचटीटीपी अनुरोध में यह हेडर होगा: Authorization: Bearer RANDOM-TOKEN
`canonical_id`	स्ट्रिंग; ज़रूरी नहीं डाउनलोड किए गए संग्रह का कैननिकल आईडी. अगर बताया गया है और खाली नहीं है, तो बेज़ल कैश मेमोरी से संग्रह नहीं लेगा, जब तक कि इसे उसी कैननिकल आईडी वाले अनुरोध के ज़रिए कैश मेमोरी में नहीं जोड़ा गया हो.
`downloaded_file_name`	स्ट्रिंग; वैकल्पिक डाउनलोड किए गए jar फ़ाइल को असाइन किया गया फ़ाइल नाम
`integrity`	स्ट्रिंग; वैकल्पिक डाउनलोड की गई फ़ाइल के सब-सोर्स इंटिग्रिटी फ़ॉर्मैट में, उम्मीद के मुताबिक चेकसम. यह डाउनलोड की गई फ़ाइल के चेकसम से मेल खाना चाहिए. _चेकसम को शामिल न करना सुरक्षा के लिहाज़ से जोखिम भरा है, क्योंकि रिमोट फ़ाइलों में बदलाव हो सकता है._ इस फ़ील्ड को शामिल न करने पर, आपका बिल्ड पूरी तरह से सुरक्षित नहीं रहेगा. डेवलपमेंट को आसान बनाना ज़रूरी नहीं है. हालांकि, शिपिंग से पहले इस एट्रिब्यूट या `sha256` को सेट करना ज़रूरी है.
`netrc`	स्ट्रिंग; वैकल्पिक पुष्टि करने के लिए .netrc फ़ाइल की जगह
`sha256`	स्ट्रिंग; वैकल्पिक डाउनलोड की गई फ़ाइल का अनुमानित SHA-256. यह डाउनलोड की गई फ़ाइल के SHA-256 से मेल खाना चाहिए. _SHA-256 को हटाना सुरक्षा के लिहाज़ से जोखिम भरा है, क्योंकि रिमोट फ़ाइलों में बदलाव हो सकता है._ इस फ़ील्ड को हटाने पर, आपका बिल्ड पूरी तरह से सुरक्षित नहीं रहेगा. डेवलपमेंट को आसान बनाना ज़रूरी नहीं है. हालांकि, शिपिंग से पहले इस एट्रिब्यूट या `Integrity` को सेट करना ज़रूरी है.
`url`	स्ट्रिंग; ज़रूरी नहीं उस फ़ाइल का यूआरएल जिसे Basel को उपलब्ध कराया जाएगा. यह फ़ाइल, http या https यूआरएल होनी चाहिए. दूसरे वेबलिंक पर ले जाने वाले यूआरएल को इसमें शामिल किया जाता है. पुष्टि करने की सुविधा काम नहीं करती. urls पैरामीटर की मदद से ज़्यादा सुविधाएं मिल सकती हैं. इसकी मदद से, फ़ेच करने के लिए वैकल्पिक यूआरएल तय किए जा सकते हैं. यूआरएल के आखिर में `.jar` होना चाहिए.
`urls`	स्ट्रिंग की सूची; वैकल्पिक किसी फ़ाइल के यूआरएल की सूची, जिसे Bazel के लिए उपलब्ध कराया जाएगा. हर एंट्री कोई फ़ाइल, http या https यूआरएल होनी चाहिए. दूसरे वेबलिंक पर ले जाने वाले यूआरएल को इसमें शामिल किया जाता है. प्रमाणीकरण समर्थित नहीं है. यूआरएल को क्रम से तब तक आज़माया जाता है, जब तक कि कोई एक काम न कर जाए. इसलिए, आपको पहले लोकल मिरर की सूची बनानी चाहिए. अगर सभी डाउनलोड फ़ेल हो जाते हैं, तो नियम लागू नहीं होगा. सभी यूआरएल का आखिर में `.jar` होना चाहिए.