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

इन फ़ंक्शन को @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_file_integrity, remote_file_urls, 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 डिक्शनरी: स्ट्रिंग -> स्ट्रिंग; ज़रूरी नहीं है

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

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

यह फ़ाइल के रिलेटिव पाथ (कुंजी) के मैप से उसकी इंटिग्रिटी वैल्यू (वैल्यू) बनाता है. ये रिलेटिव पाथ, `remote_file_urls` एट्रिब्यूट में मौजूद फ़ाइलों (कुंजी) से मैप होने चाहिए.

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

यह रिलेटिव पाथ (कुंजी) के मैप से यूआरएल (वैल्यू) की सूची बनाता है. इन यूआरएल को डाउनलोड किया जाता है और डेटाबेस में ओवरले की गई फ़ाइलों के तौर पर उपलब्ध कराया जाता है. यह तब काम आता है, जब आपको किसी मौजूदा डेटाबेस में WORKSPACE या BUILD.bazel फ़ाइलें जोड़नी हों. `patches` एट्रिब्यूट में पैच लागू करने से पहले, फ़ाइलें डाउनलोड की जाती हैं. साथ ही, यूआरएल की सूची में एक ही फ़ाइल के सभी संभावित मिरर होने चाहिए. जब तक कोई यूआरएल काम नहीं करता, तब तक यूआरएल को क्रम से आज़माया जाता है.

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

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

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

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

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

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

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

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

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

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

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

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