बेज़ल रजिस्ट्री

समस्या की शिकायत करें सोर्स देखें

Nightly · 9.1 · 9.0 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 8.1

Bazel, डिपेंडेंसी की जानकारी पाने के लिए, Bazel रजिस्ट्रियों से अनुरोध करता है. ये, Bazel मॉड्यूल के डेटाबेस होते हैं. Bazel, सिर्फ़ एक तरह के रजिस्ट्रियों — इंडेक्स रजिस्ट्रियों — का इस्तेमाल करता है. ये स्थानीय डायरेक्ट्री या स्टैटिक एचटीटीपी सर्वर होते हैं, जो किसी खास फ़ॉर्मैट में काम करते हैं.

इंडेक्स रजिस्ट्री

इंडेक्स रजिस्ट्री, स्थानीय डायरेक्ट्री या स्टैटिक एचटीटीपी सर्वर होती है. इसमें मॉड्यूल की सूची के बारे में जानकारी होती है. जैसे, उनका होम पेज, उन्हें मैनेज करने वाले लोग, हर वर्शन की MODULE.bazel फ़ाइल, और हर वर्शन का सोर्स पाने का तरीका. खास तौर पर, इसे सोर्स के संग्रह को खुद से दिखाने की ज़रूरत नहीं होती.

इंडेक्स रजिस्ट्री का फ़ॉर्मैट यह होना चाहिए:

• /bazel_registry.json: यह एक वैकल्पिक JSON फ़ाइल है. इसमें रजिस्ट्री के लिए मेटाडेटा होता है.
• /modules: यह एक डायरेक्ट्री है. इसमें इस रजिस्ट्री में मौजूद हर मॉड्यूल के लिए एक सब-डायरेक्ट्री होती है
• /modules/$MODULE: यह एक डायरेक्ट्री है. इसमें $MODULE नाम के मॉड्यूल के हर वर्शन के लिए एक सब-डायरेक्ट्री होती है. साथ ही, इसमें metadata.json फ़ाइल भी होती है. इसमें इस मॉड्यूल के लिए मेटाडेटा होता है.
• /modules/$MODULE/$VERSION: यह एक डायरेक्ट्री है. इसमें ये फ़ाइलें होती हैं:
  • MODULE.bazel: यह इस मॉड्यूल वर्शन की MODULE.bazel फ़ाइल है. ध्यान दें कि यह MODULE.bazel फ़ाइल, Bazel की बाहरी डिपेंडेंसी को हल करने के दौरान पढ़ी जाती है. यह सोर्स के संग्रह की फ़ाइल नहीं होती. हालांकि, अगर रजिस्ट्री से अलग कोई सेटिंग की गई हो, तो ऐसा हो सकता है. यह भी ध्यान दें कि रिलीज़ का वर्शन सेट करने के लिए, इस फ़ाइल का इस्तेमाल करना सबसे अच्छा होता है. सोर्स के संग्रह की MODULE.bazel फ़ाइल में ऐसा न करें. मॉड्यूल वर्शन के बारे में ज़्यादा जानने के लिए, अक्सर पूछे जाने वाले सवाल देखें.
  • source.json: यह एक JSON फ़ाइल है. इसमें इस मॉड्यूल वर्शन का सोर्स पाने के तरीके के बारे में जानकारी होती है
  • patches/: यह एक वैकल्पिक डायरेक्ट्री है. इसमें पैच फ़ाइलें होती हैं. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब source.json में "archive" टाइप हो
  • overlay/: यह एक वैकल्पिक डायरेक्ट्री है. इसमें ओवरले फ़ाइलें होती हैं. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब source.json में "archive" टाइप हो

bazel_registry.json

bazel_registry.json एक वैकल्पिक फ़ाइल है. इसमें पूरे रजिस्ट्री पर लागू होने वाला मेटाडेटा होता है. इसमें ये फ़ील्ड हो सकते हैं:

• mirrors: यह स्ट्रिंग का एक कलेक्शन है. इसमें सोर्स के संग्रह के लिए इस्तेमाल किए जाने वाले मिरर की सूची होती है.
  • मिरर किया गया यूआरएल, मिरर और मॉड्यूल के सोर्स यूआरएल को जोड़कर बनता है. यह सोर्स यूआरएल, प्रोटोकॉल के बिना, उसकी source.json फ़ाइल में दिया जाता है. उदाहरण के लिए, अगर किसी मॉड्यूल का सोर्स यूआरएल https://foo.com/bar/baz है और mirrors में ["https://mirror1.com/", "https://example.com/mirror2/"] शामिल है, तो Bazel इन यूआरएल को क्रम से आज़माएगा: https://mirror1.com/foo.com/bar/baz, https://example.com/mirror2/foo.com/bar/baz. इसके बाद, ओरिजनल सोर्स यूआरएल https://foo.com/bar/baz को आज़माएगा.
• module_base_path: यह एक स्ट्रिंग है. इसमें source.json फ़ाइल में local_path टाइप वाले मॉड्यूल के लिए, बेस पाथ की जानकारी होती है

metadata.json

metadata.json एक वैकल्पिक JSON फ़ाइल है. इसमें मॉड्यूल के बारे में जानकारी होती है. इसमें ये फ़ील्ड शामिल होते हैं:

• versions: यह स्ट्रिंग का एक कलेक्शन है. इसमें हर स्ट्रिंग, इस रजिस्ट्री में उपलब्ध मॉड्यूल के एक वर्शन को दिखाती है. यह कलेक्शन, मॉड्यूल डायरेक्ट्री के चाइल्ड से मेल खाना चाहिए.
• yanked_versions: यह एक JSON ऑब्जेक्ट है. इसमें इस मॉड्यूल के yanked versions वर्शन की जानकारी होती है. कुंजियां, yank करने के लिए वर्शन होनी चाहिए. साथ ही, वैल्यू में यह जानकारी होनी चाहिए कि वर्शन को yank क्यों किया गया है. इसमें ज़्यादा जानकारी के लिए, एक लिंक भी होना चाहिए.

ध्यान दें कि बीसीआर के लिए, metadata.json फ़ाइल में ज़्यादा जानकारी की ज़रूरत होती है.

source.json

source.json एक ज़रूरी JSON फ़ाइल है. इसमें मॉड्यूल के किसी खास वर्शन को पाने के तरीके के बारे में जानकारी होती है. इस फ़ाइल का स्कीमा, इसके type फ़ील्ड पर निर्भर करता है. इसकी डिफ़ॉल्ट वैल्यू archive होती है.

• अगर type की वैल्यू archive है (डिफ़ॉल्ट वैल्यू), तो इस मॉड्यूल वर्शन को http_archive रेपो नियम से बैक अप किया जाता है. इसे किसी दिए गए यूआरएल से संग्रह डाउनलोड करके और उसके कॉन्टेंट को निकालकर पाया जाता है. यह इन फ़ील्ड के साथ काम करता है:
  • url: यह एक स्ट्रिंग है. इसमें सोर्स के संग्रह का यूआरएल होता है
  • mirror_urls: यह स्ट्रिंग की एक सूची है. इसमें सोर्स के संग्रह के मिरर यूआरएल होते हैं. बैकअप के तौर पर, url के बाद यूआरएल को क्रम से आज़माया जाता है.
  • integrity: यह एक स्ट्रिंग है. इसमें संग्रह का सबरिसॉर्स इंटिग्रिटी चेकसम होता है
  • strip_prefix: यह एक स्ट्रिंग है. इसमें सोर्स के संग्रह को निकालते समय, डायरेक्ट्री के प्रीफ़िक्स को हटाने की जानकारी होती है
  • overlay: यह एक JSON ऑब्जेक्ट है. इसमें निकाले गए संग्रह के ऊपर लेयर करने के लिए, ओवरले फ़ाइलें होती हैं. पैच फ़ाइलें, /modules/$MODULE/$VERSION/overlay डायरेक्ट्री में मौजूद होती हैं. कुंजियां, ओवरले फ़ाइल के नाम होती हैं. साथ ही, वैल्यू में ओवरले फ़ाइल का इंटिग्रिटी चेकसम होता है. पैच फ़ाइलों से पहले, ओवरले लागू किए जाते हैं.
  • patches: यह एक JSON ऑब्जेक्ट है. इसमें निकाले गए संग्रह पर लागू करने के लिए, पैच फ़ाइलें होती हैं. पैच फ़ाइलें, /modules/$MODULE/$VERSION/patches डायरेक्ट्री में मौजूद होती हैं. कुंजियां, पैच फ़ाइल के नाम होती हैं. साथ ही, वैल्यू में पैच फ़ाइल का इंटिग्रिटी चेकसम होता है. ओवरले फ़ाइलों के बाद, पैच लागू किए जाते हैं. ये उसी क्रम में लागू किए जाते हैं जिस क्रम में ये patches में दिखते हैं.
  • patch_strip: यह एक संख्या है. यह Unix patch के --strip आर्ग्युमेंट के बराबर होती है.
  • archive_type: यह एक स्ट्रिंग है. इसमें डाउनलोड की गई फ़ाइल का संग्रह टाइप होता है. यह type पर मौजूद http_archive के बराबर होता है.
• अगर type की वैल्यू git_repository है, तो इस मॉड्यूल वर्शन को git_repository रेपो नियम से बैक अप किया जाता है. इसे Git रिपॉज़िटरी को क्लोन करके पाया जाता है.
  • ये फ़ील्ड काम करते हैं. इन्हें सीधे तौर पर, git_repository रेपो नियम में फ़ॉरवर्ड किया जाता है: remote, commit, shallow_since, tag, init_submodules, verbose, strip_prefix, और patch_strip.
  • patches: यह एक JSON ऑब्जेक्ट है. इसमें क्लोन की गई रिपॉज़िटरी पर लागू करने के लिए, पैच फ़ाइलें होती हैं. पैच फ़ाइलें, /modules/$MODULE/$VERSION/patches डायरेक्ट्री में मौजूद होती हैं. कुंजियां, पैच फ़ाइल के नाम होती हैं. साथ ही, वैल्यू में पैच फ़ाइल का इंटिग्रिटी चेकसम होता है. पैच, उसी क्रम में लागू किए जाते हैं जिस क्रम में ये patches में दिखते हैं.
• अगर type की वैल्यू local_path है, तो इस मॉड्यूल वर्शन को a local_repository रेपो नियम से बैक अप किया जाता है. इसे लोकल डिस्क पर मौजूद किसी डायरेक्ट्री से सिमलंक किया जाता है. यह इस फ़ील्ड के साथ काम करता है:
  • path: यह रेपो का लोकल पाथ है. इसकी गिनती इस तरह की जाती है:
    • अगर path एक ऐब्सलूट पाथ है, तो यह वैसा ही रहता है
    • अगर path एक रिलेटिव पाथ है और module_base_path एक ऐब्सलूट पाथ है, तो यह <module_base_path>/<path> में बदल जाता है
    • अगर path और module_base_path, दोनों रिलेटिव पाथ हैं, तो यह <registry_path>/<module_base_path>/<path> में बदल जाता है. रजिस्ट्री को स्थानीय तौर पर होस्ट किया जाना चाहिए. साथ ही, इसका इस्तेमाल --registry=file://<registry_path> से किया जाना चाहिए. ऐसा न करने पर, Bazel एक गड़बड़ी दिखाएगा

Bazel Central Registry

Bazel Central Registry (बीसीआर), https://bcr.bazel.build/ पर मौजूद एक इंडेक्स रजिस्ट्री है. इसके कॉन्टेंट को GitHub रेपो bazelbuild/bazel-central-registry से बैक अप किया जाता है. इसके कॉन्टेंट को, https://registry.bazel.build/ पर मौजूद वेब फ़्रंटएंड का इस्तेमाल करके ब्राउज़ किया जा सकता है.

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

बीसीआर के लिए, सामान्य इंडेक्स रजिस्ट्री के फ़ॉर्मैट के अलावा, हर मॉड्यूल वर्शन के लिए presubmit.yml फ़ाइल की ज़रूरत होती है (/modules/$MODULE/$VERSION/presubmit.yml). इस फ़ाइल में, कुछ ज़रूरी बिल्ड और टेस्ट टारगेट की जानकारी होती है. इनका इस्तेमाल, इस मॉड्यूल वर्शन की वैधता की जांच करने के लिए किया जा सकता है. बीसीआर की सीआई पाइपलाइन भी इसका इस्तेमाल, मॉड्यूल के बीच इंटरऑपरेबिलिटी पक्का करने के लिए करती है.

रजिस्ट्रियां चुनना

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

अगर आपकी रजिस्ट्री GitHub पर होस्ट की गई है (उदाहरण के लिए, bazelbuild/bazel-central-registry के फ़ोर्क के तौर पर), तो --registry की वैल्यू के लिए, raw.githubusercontent.com में GitHub का रॉ पता होना चाहिए. उदाहरण के लिए, main ब्रांच पर my-org फ़ोर्क, आपको सेट करना होगा --registry=https://raw.githubusercontent.com/my-org/bazel-central-registry/main/.

--registry फ़्लैग का इस्तेमाल करने पर, Bazel Central Registry डिफ़ॉल्ट रूप से इस्तेमाल नहीं की जाती. हालांकि, --registry=https://bcr.bazel.build जोड़कर, इसे वापस जोड़ा जा सकता है.