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