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

किसी समस्या की शिकायत करें सोर्स देखें Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

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_FULLS_URLS_AS_DEFAULT_CANONICAL_ID=0 से बंद किया जा सकता है.

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

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

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

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

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

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

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

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

patch_cmds_win स्ट्रिंग की सूची; वैकल्पिक

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

patch_tool स्ट्रिंग; वैकल्पिक

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

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

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

remote_patch_strip पूर्णांक; ज़रूरी नहीं

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

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

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

repo_mapping शब्दकोश: स्ट्रिंग -> स्ट्रिंग; ज़रूरी है

लोकल डेटा स्टोर करने की जगह के नाम से ग्लोबल डेटा स्टोर करने की जगह के नाम की डिक्शनरी. इससे, इस रिपॉज़िटरी की डिपेंडेंसी के लिए, वर्कस्पेस डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है.

उदाहरण के लिए, "@foo": "@bar" वाली एंट्री से पता चलता है कि जब भी यह रिपॉज़िटरी, `@foo` पर निर्भर हो (जैसे, `@foo//some:target` पर निर्भरता), तो उसे ग्लोबल तौर पर बताए गए `@bar` (`@bar//some:target`) में उस डिपेंडेंसी को हल करना चाहिए.

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

डाउनलोड की गई फ़ाइल का अनुमानित 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`). अगर दिया गया प्रीफ़िक्स, संग्रह में मौजूद किसी डायरेक्ट्री से मेल नहीं खाता है, तो Bazel गड़बड़ी का मैसेज दिखाएगा.

type स्ट्रिंग; वैकल्पिक

डाउनलोड की गई फ़ाइल का संग्रह टाइप. डिफ़ॉल्ट रूप से, संग्रह का टाइप यूआरएल के फ़ाइल एक्सटेंशन से तय होता है. अगर फ़ाइल का कोई एक्सटेंशन मौजूद नहीं है, तो इनमें से किसी एक का इस्तेमाल करें: `"zip"`, `"jar"`, `"var"`, `"aar"`, `"tar"`, `"tar.gz"`, `"tgz"`, `"tar.xz"`, `"txz"`, `"tar.zst"`, `"z`, `"tar.zst"`, `"tz`."

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

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

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

उदाहरण: मान लें कि आपको अपने कस्टम नियमों के लिए 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 स्ट्रिंग; ज़रूरी नहीं

डाउनलोड की गई फ़ाइल का कैननिकल आईडी. अगर कैश मेमोरी में सेव की गई फ़ाइल का कैननिकल आईडी दिया गया है और वह खाली नहीं है, तो Bazel उस फ़ाइल को कैश मेमोरी से तब तक नहीं लेगा, जब तक कि उसे उसी कैननिकल आईडी वाले अनुरोध से कैश मेमोरी में नहीं जोड़ा गया है. अगर कोई वैल्यू नहीं दी गई है या वह खाली है, तो Bazel डिफ़ॉल्ट रूप से फ़ाइल के यूआरएल का इस्तेमाल, कैननिकल आईडी के तौर पर करता है. इससे, यूआरएल को अपडेट करने के साथ-साथ हैश को अपडेट न करने की सामान्य गलती को पकड़ने में मदद मिलती है. इस वजह से, ऐसे बिल्ड बनते हैं जो लोकल तौर पर काम करते हैं, लेकिन कैश मेमोरी में फ़ाइल न होने पर, मशीनों पर काम नहीं करते. इस व्यवहार को --repo_env=BAZEL_HTTP_FULLS_URLS_AS_DEFAULT_CANONICAL_ID=0 से बंद किया जा सकता है.

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

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

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

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

integrity स्ट्रिंग; वैकल्पिक

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

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

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

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

लोकल डेटा स्टोर करने की जगह के नाम से ग्लोबल डेटा स्टोर करने की जगह के नाम की डिक्शनरी. इससे, इस रिपॉज़िटरी की डिपेंडेंसी के लिए, वर्कस्पेस डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है.

उदाहरण के लिए, "@foo": "@bar" वाली एंट्री से पता चलता है कि जब भी यह रिपॉज़िटरी, `@foo` पर निर्भर हो (जैसे, `@foo//some:target` पर निर्भरता), तो उसे ग्लोबल तौर पर बताए गए `@bar` (`@bar//some:target`) में उस डिपेंडेंसी को हल करना चाहिए.

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

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

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

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

किसी यूआरएल से jar डाउनलोड करता है और उसे 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",
  )

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

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

डाउनलोड की गई फ़ाइल का कैननिकल आईडी. अगर कैश मेमोरी में सेव की गई फ़ाइल का कैननिकल आईडी दिया गया है और वह खाली नहीं है, तो Bazel उस फ़ाइल को कैश मेमोरी से तब तक नहीं लेगा, जब तक कि उसे उसी कैननिकल आईडी वाले अनुरोध से कैश मेमोरी में नहीं जोड़ा गया है. अगर कोई वैल्यू नहीं दी गई है या वह खाली है, तो Bazel डिफ़ॉल्ट रूप से फ़ाइल के यूआरएल का इस्तेमाल, कैननिकल आईडी के तौर पर करता है. इससे, यूआरएल को अपडेट करने के साथ-साथ हैश को अपडेट न करने की सामान्य गलती को पकड़ने में मदद मिलती है. इस वजह से, ऐसे बिल्ड बनते हैं जो लोकल तौर पर काम करते हैं, लेकिन कैश मेमोरी में फ़ाइल न होने पर, मशीनों पर काम नहीं करते. इस व्यवहार को --repo_env=BAZEL_HTTP_FULLS_URLS_AS_DEFAULT_CANONICAL_ID=0 से बंद किया जा सकता है.

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

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

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

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

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

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

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

लोकल डेटा स्टोर करने की जगह के नाम से ग्लोबल डेटा स्टोर करने की जगह के नाम की डिक्शनरी. इससे, इस रिपॉज़िटरी की डिपेंडेंसी के लिए, वर्कस्पेस डिपेंडेंसी रिज़ॉल्यूशन को कंट्रोल किया जा सकता है.

उदाहरण के लिए, "@foo": "@bar" वाली एंट्री से पता चलता है कि जब भी यह रिपॉज़िटरी, `@foo` पर निर्भर हो (जैसे, `@foo//some:target` पर निर्भरता), तो उसे ग्लोबल तौर पर बताए गए `@bar` (`@bar//some:target`) में उस डिपेंडेंसी को हल करना चाहिए.

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

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

url स्ट्रिंग; वैकल्पिक

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

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

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