इस पेज पर रिपॉज़िटरी नियम बनाने का तरीका बताया गया है. साथ ही, ज़्यादा जानकारी के लिए उदाहरण दिए गए हैं.
रिपॉज़िटरी (डेटा स्टोर करने की जगह) एक ऐसा नियम है जिसे सिर्फ़ WORKSPACE
फ़ाइल में
इस्तेमाल किया जा सकता है और यह बेज़ल की लोडिंग फ़ेज़ में बिना रूब्रिक वाली कार्रवाई
को चालू करता है. डेटा स्टोर करने के हर बाहरी नियम अपना खुद का BUILD
फ़ाइल और आर्टफ़ैक्ट इस्तेमाल करके, अपना फ़ाइल फ़ोल्डर बनाते हैं. इनका इस्तेमाल तीसरे पक्ष की लाइब्रेरी (जैसे, Maven पैकेज की गई लाइब्रेरी) के आधार पर किया जा सकता है. साथ ही, इसका इस्तेमाल करके, सर्वर बेज़ल के लिए खास तौर पर BUILD
फ़ाइलें जनरेट की जा सकती हैं.
रिपॉज़िटरी नियम बनाना
किसी .bzl
फ़ाइल में, नया डेटा स्टोर करने का नियम बनाने के लिए
repository_rule फ़ंक्शन का इस्तेमाल करें
और उसे ग्लोबल वैरिएबल में सेव करें.
कस्टम डेटा स्टोर करने के नियम का इस्तेमाल, डेटा स्टोर करने के मूल नियम की तरह ही किया जा सकता है. इसमें
एक ज़रूरी name
एट्रिब्यूट है और इसकी बिल्ड फ़ाइलों में मौजूद हर टारगेट को @<name>//package:target
कहा जा सकता है. यहां <name>
, name
एट्रिब्यूट की वैल्यू है.
नियम तब बनाया जाता है, जब आप उसे साफ़ तौर पर बनाते हैं या वह
बिल्डर पर निर्भर करता है. इस मामले में, Bazel अपना implementation
फ़ंक्शन लागू करेगा. इस फ़ंक्शन में रिपॉज़िटरी, उसके कॉन्टेंट, और BUILD
फ़ाइलों को बनाने का तरीका बताया गया है.
विशेषताएं
एट्रिब्यूट, नियम का तर्क होता है, जैसे कि url
या sha256
. रिपॉज़िटरी के नियम तय करते समय, आपको
एट्रिब्यूट और उनके टाइप की सूची बनानी होगी.
local_repository = repository_rule(
implementation=_impl,
local=True,
attrs={"path": attr.string(mandatory=True)})
किसी एट्रिब्यूट को ऐक्सेस करने के लिए, repository_ctx.attr.<attribute_name>
का इस्तेमाल करें.
सभी repository_rule
में पूरी तरह से तय एट्रिब्यूट होते हैं (जैसे कि बिल्ड
नियम). दो इंप्लिसिट एट्रिब्यूट name
(बिल्ड के नियमों की तरह) और
repo_mapping
हैं. डेटा स्टोर करने की जगह के नियम का नाम repository_ctx.name
से ऐक्सेस किया जा सकता है. repo_mapping
का मतलब वही है जो
निजी डेटा स्टोर करने के नियमों
local_repository
और
new_local_repository
पर लागू होता है.
अगर एट्रिब्यूट का नाम _
से शुरू होता है, तो यह निजी होता है और उपयोगकर्ता इसे सेट नहीं कर सकते.
लागू करने की सुविधा
डेटा स्टोर करने के हर नियम में implementation
फ़ंक्शन होना ज़रूरी है. इसमें नियम का
तर्क होता है और उसे लोडिंग चरण में सख्ती से लागू किया जाता है.
इस फ़ंक्शन में सिर्फ़ एक इनपुट पैरामीटर repository_ctx
है. दिए गए पैरामीटर के मुताबिक नियम फिर से जनरेट किया जा सकता है, यह दिखाने के लिए फ़ंक्शन None
उदाहरण के लिए, एक नियम की वैल्यू को ट्रैक करने के लिए एक git डेटा स्टोर करने की जगह को ट्रैक करने का मतलब है कि मूल रूप से तय की गई फ़्लोटिंग ब्रांच के बजाय एक खास कमिटी आइडेंटिफ़ायर रिटर्न करना होगा.
इनपुट पैरामीटर repository_ctx
का इस्तेमाल, एट्रिब्यूट की वैल्यू को ऐक्सेस करने और बाइनरी ढूंढने, बाइनरी ढूंढने, डेटा स्टोर करने की जगह में फ़ाइल बनाने या इंटरनेट से फ़ाइल डाउनलोड करने के लिए किया जा सकता है. ज़्यादा जानकारी के लिए लाइब्रेरी देखें. उदाहरण:
def _impl(repository_ctx):
repository_ctx.symlink(repository_ctx.attr.path, "")
local_repository = repository_rule(
implementation=_impl,
...)
लागू करने का फ़ंक्शन कब शुरू होता है?
डेटा स्टोर करने की जगह को लागू करने का फ़ंक्शन तब निष्पादित किया जाता है, जब Bazel को डेटा स्टोर करने की उस जगह से किसी टारगेट की ज़रूरत होती है, उदाहरण के लिए, जब कोई दूसरा टारगेट (किसी दूसरे डेटा संग्रह की जगह में) इस पर निर्भर होता है या जब कमांड फ़ील्ड में उसका ज़िक्र होता है. इसके बाद, लागू करने की सुविधा का फ़ाइल सिस्टम में रिपॉज़िटरी बनाने की उम्मीद की जाती है. इसे रिपॉज़िटरी "फ़ेचिंग" कहा जाता है.
सामान्य टारगेट के उलट, डेटा स्टोर करने की जगह में बदलाव होने पर, डेटा स्टोर करने की जगह को फिर से फ़ेच करना ज़रूरी नहीं होता. ऐसा कुछ वजहों से बेज़ेल या तो बदलावों की पहचान नहीं कर पाता या हर बिल्ड पर बहुत ज़्यादा ओवरहेड बना देता है (उदाहरण के लिए, ऐसी चीज़ें जो नेटवर्क से फ़ेच की जाती हैं). इसलिए, डेटा स्टोर करने की जगह को फिर से सिर्फ़ तब फ़ेच किया जाता है, जब इनमें से कोई एक चीज़ बदलती है:
WORKSPACE
फ़ाइल में, डेटा स्टोर करने की जगह के एलान में पास किए गए पैरामीटर.- Starlark कोड में रिपॉज़िटरी को लागू करना शामिल है.
repository_rule
केenviron
एट्रिब्यूट के साथ बताए गए किसी भी एनवायरमेंट वैरिएबल की वैल्यू. इन एनवायरमेंट वैरिएबल की वैल्यू, कमांड लाइन पर--action_env
फ़्लैग (हालांकि, फ़्लैग की वजह से बिल्ड की हर कार्रवाई अमान्य हो जाएगी) पर हार्ड वायर हो सकती है.- किसी भी फ़ाइल का कॉन्टेंट,
read()
,execute()
, औरrepository_ctx
के ऐसे ही तरीकों से भेजा जाता है जिन्हें लेबल की मदद से बताया जाता है. जैसे,//mypkg:label.txt
, लेकिनmypkg/label.txt
से नहीं. bazel sync
कब चलाया जाएगा.
repository_rule
के दो पैरामीटर होते हैं जो डेटा स्टोर करने की जगह को फिर से फ़ेच किए जाने पर कंट्रोल करते हैं:
- अगर
configure
फ़्लैग सेट किया जाता है, तो--configure
पैरामीटर को पास करने पर, डेटा स्टोर करने की जगह को सिर्फ़bazel sync
पर फिर से फ़ेच किया जाता है (अगर एट्रिब्यूट को सेट नहीं किया जाता, तो इस कमांड से फिर से फ़ेच नहीं होगा) अगर ऊपर बताए गए मामलों के अलावा,
local
फ़्लैग सेट किया जाता है, तो डेटा स्टोर करने की जगह को बैज के सर्वर को रीस्टार्ट करने पर या डेटा स्टोर करने की जगह के एलान पर असर डालने वाली किसी फ़ाइल (जैसे,WORKSPACE
फ़ाइल या फ़ाइल लोड होने पर) को भी फिर से फ़ेच किया जाता है. इससे कोई फ़र्क़ नहीं पड़ता कि डेटा स्टोर करने की जगह या उसके कोड में एलान किया गया है या नहीं.इन मामलों में, डेटा स्टोर करने की गैर-स्थानीय जगहों को फिर से फ़ेच नहीं किया जाता. इसकी वजह यह है कि इन रिपॉज़िटरी को नेटवर्क से बात करने वाला माना जाता है या ये महंगे होते हैं.
लागू करने वाला फ़ंक्शन रीस्टार्ट हो रहा है
जब डेटा किसी डिपेंडेंसी के लिए अनुरोध करता है, तो फ़ंक्शन को फिर से शुरू किया जा सकता है. इस तरह के मामलों में, लागू करने का फ़ंक्शन बंद हो जाएगा, डिपेंडेंसी का समाधान हो जाएगा, और डिपेंडेंसी का समाधान हो जाने के बाद फ़ंक्शन फिर से लागू हो जाएगा. ग़ैर-ज़रूरी रीस्टार्ट से बचने के लिए (जो महंगे होते हैं, क्योंकि नेटवर्क का ऐक्सेस दोहराना पड़ सकता है), लेबल के आर्ग्युमेंट को प्रीफ़ेच किया जाता है. हालांकि, यह ज़रूरी है कि लेबल के सभी आर्ग्युमेंट किसी मौजूदा फ़ाइल पर ठीक किए जा सकें. ध्यान दें कि किसी ऐसे स्ट्रिंग या लेबल से बने पाथ को हल करने से अब भी रीस्टार्ट हो सकता है जो सिर्फ़ फ़ंक्शन के चलने के दौरान बनाया गया था.
बाहरी डेटा स्टोर करने की जगहों को फिर से फ़ेच करने के लिए
कभी-कभी, डेटा स्टोर करने की बाहरी जगह की परिभाषा या डिपेंडेंसी में बिना कोई बदलाव किए, वह पुराना हो सकता है. उदाहरण के लिए, डेटा स्टोर करने की जगह पर डेटा फ़ेच करने वाले सोर्स,
तीसरे पक्ष के डेटा स्टोर करने की किसी खास जगह की किसी खास ब्रांच को फ़ॉलो कर सकते हैं. साथ ही, उस ब्रांच पर नई प्रतिबद्धताएं भी उपलब्ध हो जाती हैं. इस मामले में, आप बेज़ल से bazel sync
पर कॉल करके, सभी बाहरी रिपॉज़िटरी को फिर से फ़ेच करने के लिए कह सकते हैं.
इसके अलावा, कुछ नियम स्थानीय मशीन की जांच करते हैं और स्थानीय मशीन को अपग्रेड करने पर पुराना हो सकता है. यहां आप बेज़ल से सिर्फ़ उन बाहरी डेटा स्टोर करने की जगहों को फिर से फ़ेच करने के लिए कह सकते हैं जहां repository_rule
परिभाषा में configure
एट्रिब्यूट सेट किया गया है. इसके लिए, bazel sync --configure
का इस्तेमाल करें.
उदाहरण
C++ अपने-आप कॉन्फ़िगर किया गया टूलचेन: यह एक रिपॉज़िटरी नियम का इस्तेमाल करता है, ताकि स्थानीय C++ कंपाइलर, C++ कंपाइलर के साथ काम करने वाले एनवायरमेंट और फ़्लैग करके, Bazel के लिए C++ कॉन्फ़िगरेशन फ़ाइलों को अपने-आप बनाया जा सके.
डेटा स्टोर करने की जगह कई
repository_rule
का इस्तेमाल करके, उन डिपेंडेंसी की सूची के बारे में बताती है जिन्हें Go के नियमों का इस्तेमाल करना होता है.rule_jvm_external डिफ़ॉल्ट रूप से
@maven
नाम का एक बाहरी रिपॉज़िटरी बनाता है, जो कि ट्रांज़िशनिव डिपेंडेंसी ट्री में हर मेवन आर्टफ़ैक्ट के लिए बिल्ड टारगेट जनरेट करता है.