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

@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/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 डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी नहीं

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यह पैच फ़ाइल के यूआरएल का मैप, जिसमें पूरी सुरक्षा देने की सुविधा मौजूद है. इसे संग्रह से निकालने के बाद और `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- {/2}. `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"`, `bts`, `btar.zst"`.

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

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

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

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

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)

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

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

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

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

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

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

http_jar

http_jar(name, auth_patterns, canonical_id, downloaded_file_name, integrity, netrc, repo_mapping,
         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",
  )

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

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

एट्रिब्यूट

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

डेटा स्टोर करने की इस जगह के लिए खास नाम.

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

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

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

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

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

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

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