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

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 7.4 . 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)

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

यह इन फ़ाइल एक्सटेंशन के साथ काम करता है: "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 String; ज़रूरी नहीं

रिपॉज़िटरी डायरेक्ट्री से जुड़ी डेस्टिनेशन डायरेक्ट्री. `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 रखा जा सकता है. जैसे, BUILD.new-repo-name, जिससे इसे रिपॉज़िटरी की असल BUILD फ़ाइलों से अलग किया जा सकता है. build_file या build_file_content में से किसी एक की जानकारी दी जा सकती है, लेकिन दोनों की नहीं.

build_file_content String; ज़रूरी नहीं

इस डेटा स्टोर करने की जगह के लिए BUILD फ़ाइल का कॉन्टेंट. build_file या build_file_content में से किसी एक की जानकारी दी जा सकती है, लेकिन दोनों की नहीं.

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

डाउनलोड किए गए संग्रह का कैननिकल आईडी. अगर कैननिकल आईडी दिया गया है और वह खाली नहीं है, तो bazel कैश मेमोरी से संग्रह नहीं लेगा. ऐसा तब तक नहीं होगा, जब तक कि उसे उसी कैननिकल आईडी वाले अनुरोध से कैश मेमोरी में नहीं जोड़ा गया हो.

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

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

netrc String; ज़रूरी नहीं

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

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

पैच टूल को दिए गए आर्ग्युमेंट. डिफ़ॉल्ट रूप से -p0 पर सेट होता है. हालांकि, git से जनरेट किए गए पैच के लिए आम तौर पर -p1 की ज़रूरत होगी. अगर एक से ज़्यादा -p आर्ग्युमेंट दिए जाते हैं, तो आखिरी आर्ग्युमेंट लागू होगा. अगर -p के अलावा कोई अन्य आर्ग्युमेंट दिया जाता है, तो Bazel, Bazel-नेटिव पैच लागू करने के बजाय, पैच कमांड लाइन टूल का इस्तेमाल करेगा. पैच कमांड लाइन टूल और पैच_टूल एट्रिब्यूट पर वापस जाने पर, `पैच` का इस्तेमाल किया जाएगा. इससे सिर्फ़ `पैच` एट्रिब्यूट में मौजूद पैच फ़ाइलों पर असर पड़ता है.

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

पैच लागू होने के बाद, Linux/Macos पर Bash कमांड का क्रम.

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

पैच लागू होने के बाद, Windows पर पावरशेल कमांड का क्रम. अगर यह एट्रिब्यूट सेट नहीं है, तो Windows पर Pat_cmds का इस्तेमाल किया जाएगा. इसके लिए, Bash बाइनरी का मौजूद होना ज़रूरी है.

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

इस्तेमाल की जाने वाली पैच(1) सुविधा. अगर इसका इस्तेमाल किया जा रहा है, तो Basel-नेटिव पैच को लागू करने के बजाय, Basel के बताए गए पैच टूल का इस्तेमाल किया जाएगा.

patches लेबल की सूची; ज़रूरी नहीं

उन फ़ाइलों की सूची जिन्हें संग्रह से निकालने के बाद, पैच के तौर पर लागू किया जाना है. डिफ़ॉल्ट रूप से, यह Bazel-नेटिव पैच लागू करने का तरीका इस्तेमाल करता है. यह फ़ज़ मैच और बाइनरी पैच के साथ काम नहीं करता. हालांकि, अगर `patch_tool` एट्रिब्यूट की वैल्यू दी गई है या `patch_args` एट्रिब्यूट में `-p` के अलावा कोई अन्य आर्ग्युमेंट है, तो Bazel पैच कमांड लाइन टूल का इस्तेमाल करेगा.

remote_patch_strip Integer; ज़रूरी नहीं

रिमोट पैच में मौजूद फ़ाइल के नाम से हटाए जाने वाले लीडिंग स्लैश की संख्या.

remote_patches डिकशनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी नहीं

पैच फ़ाइल के यूआरएल और उसकी इंटिग्रिटी वैल्यू का मैप. ये पैच, संग्रह को निकालने के बाद और `पैच` एट्रिब्यूट से पैच फ़ाइलें लागू करने से पहले लागू किए जाते हैं. यह Baज़ल-नेटिव पैच लागू करने की सुविधा का इस्तेमाल करता है. आपके पास `remote_patch_strip` के साथ पैच स्ट्रिप नंबर को तय करने का विकल्प होता है

sha256 String; ज़रूरी नहीं

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

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"`, `"war"`, `"aar"`, `"tar"`, `"tar.gz"`, `"tgz"`, `"tar.xz"`, `"txz"`, `"tar.zst"`, `"tzst"`, `tar.bz2`, `"ar"`, या `"deb"`.

url String; ज़रूरी नहीं

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

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

उस फ़ाइल के यूआरएल की सूची जिसे Basel को उपलब्ध कराया जाएगा. हर एंट्री कोई फ़ाइल, 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)

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

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

auth_patterns = {
    "storage.cloudprovider.com": "Bearer <password>"
}
netrc: 
machine storage.cloudprovider.com
        password RANDOM-TOKEN
एचटीटीपी के फ़ाइनल अनुरोध में यह हेडर होगा: 
Authorization: Bearer RANDOM-TOKEN

canonical_id String; ज़रूरी नहीं

डाउनलोड किए गए संग्रह का कैननिकल आईडी. अगर कैननिकल आईडी दिया गया है और वह खाली नहीं है, तो bazel कैश मेमोरी से संग्रह नहीं लेगा. ऐसा तब तक नहीं होगा, जब तक कि उसे उसी कैननिकल आईडी वाले अनुरोध से कैश मेमोरी में नहीं जोड़ा गया हो.

downloaded_file_path String; ज़रूरी नहीं

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

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

डाउनलोड की गई फ़ाइल को चलाया जा सकता है या नहीं.

integrity String; ज़रूरी नहीं

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

netrc String; ज़रूरी नहीं

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

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, sha256, url,
         urls)

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

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

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

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

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

आप "file:///path/to/file" का इस्तेमाल करके मौजूदा सिस्टम (localhost) की फ़ाइलों का संदर्भ भी दे सकते हैं" अगर आप Unix-आधारित सिस्टम पर हैं. अगर 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 String; ज़रूरी नहीं

डाउनलोड किए गए संग्रह का कैननिकल आईडी. अगर कैननिकल आईडी दिया गया है और वह खाली नहीं है, तो bazel कैश मेमोरी से संग्रह नहीं लेगा. ऐसा तब तक नहीं होगा, जब तक कि उसे उसी कैननिकल आईडी वाले अनुरोध से कैश मेमोरी में नहीं जोड़ा गया हो.

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

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

integrity String; ज़रूरी नहीं

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

netrc String; ज़रूरी नहीं

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

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

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

url String; ज़रूरी नहीं

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

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

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