इस पेज में, डेटा स्टोर करने की जगह के नियमों को तय करने का तरीका बताया गया है. साथ ही, देखें.
एक्सटर्नल रिपॉज़िटरी एक डायरेक्ट्री ट्री होता है,
इसमें ऐसी सोर्स फ़ाइलें शामिल हैं जिनका इस्तेमाल बेज़ल बिल्ड में किया जा सकता है. इन फ़ाइलों को ज़रूरत पड़ने पर जनरेट किया जाता है:
लागू होने वाले रेपो नियम पर लागू होगी. रिपोज को कई तरह से परिभाषित किया जा सकता है
तरीके है, लेकिन आखिर में हर रेपो को रेपो नियम के तहत तय किया जाता है.
बिल्ड टारगेट तय करने के लिए, बिल्ड नियमों का इस्तेमाल किया जाता है. इनका इस्तेमाल इन चीज़ों पर निर्भर रहने के लिए किया जा सकता है
तीसरे पक्ष की लाइब्रेरी (जैसे कि Maven के पैकेज की गई लाइब्रेरी) लेकिन इन्हें जनरेट करने के लिए भी
होस्ट Babel के लिए विशिष्ट BUILD फ़ाइलें चल रही हैं.
डेटा स्टोर करने के नियम की परिभाषा
.bzl फ़ाइल में,
repository_rule फ़ंक्शन का इस्तेमाल करके
डेटा संग्रह का नया नियम बनाएं और उसे ग्लोबल वैरिएबल में सेव करें. रेपो नियम तय होने के बाद,
इसे रेपो तय करने के लिए एक फ़ंक्शन के रूप में शुरू किया जा सकता है. शुरू करने का यह तरीका आम तौर पर
मॉड्यूल एक्सटेंशन को लागू करने के ज़रिए किया जाता है
फ़ंक्शन का इस्तेमाल करना होगा.
रेपो नियम की परिभाषा के दो मुख्य कॉम्पोनेंट, उसका एट्रिब्यूट स्कीमा हैं और लागू करने का फ़ंक्शन. एट्रिब्यूट स्कीमा, टेंप्लेट के नाम और टाइप तय करता है एट्रिब्यूट को रेपो नियम के लिए पास किया जाता है, और लागू करने का फ़ंक्शन होता है चलाने की ज़रूरत नहीं है.
विशेषताएं
एट्रिब्यूट, ऐसे आर्ग्युमेंट होते हैं जिन्हें रेपो नियम को लागू करने के लिए भेजा जाता है. इसका स्कीमा
रेपो नियम के ज़रिए स्वीकार की गई विशेषताओं को attrs तर्क का इस्तेमाल करके तब तय किया जाता है जब
रेपो का नियम, repository_rule को किए गए कॉल के साथ तय किया गया है. परिभाषित करने वाला एक उदाहरण
स्ट्रिंग के तौर पर url और sha256 एट्रिब्यूट:
http_archive = repository_rule(
implementation=_impl,
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 मौजूद होता है. यह है
ऐसा स्ट्रिंग एट्रिब्यूट जो कुछ हद तक जादुई तरीके से काम करता है:
रेपो नियम का इस्तेमाल शुरू करना, तो साफ़ तौर पर इसके रेपो नाम की ज़रूरत होती है; हालाँकि, जब पढ़ने के लिए
repository_ctx.attr.name का इस्तेमाल करके रेपो नियम को लागू करने का फ़ंक्शन डालने पर, यह फ़ंक्शन दिखाता है
कैननिकल रेपो नेम.
लागू करने का फ़ंक्शन
हर रेपो नियम के लिए, implementation फ़ंक्शन ज़रूरी होता है. इसमें
नियम का तर्क होना चाहिए और इसे पूरी तरह से लोड होने के चरण के दौरान लागू किया जाता है.
इस फ़ंक्शन में सिर्फ़ एक इनपुट पैरामीटर, repository_ctx है. फ़ंक्शन
यह बताने के लिए कि नियम को फिर से बनाया जा सकता हैNone
किसी खास पैरामीटर का इस्तेमाल करें या उस नियम के लिए पैरामीटर के सेट के साथ ऐसा डिक्शनरी देखें जिसमें
उस नियम को फिर से जनरेट किए जाने वाले नियम में बदल देगा, जो वही रेपो जनरेट करेगा. इसके लिए
उदाहरण के लिए, एक git रिपॉज़िटरी को ट्रैक करने वाले नियम का मतलब
किसी फ़्लोटिंग ब्रांच के बजाय, खास तौर पर जनरेट किया गया आइडेंटिफ़ायर
बताया गया है.
इनपुट पैरामीटर repository_ctx का इस्तेमाल, इनके लिए किया जा सकता है
एट्रिब्यूट की वैल्यू और नॉन-हर्मेटिक फ़ंक्शन ऐक्सेस करें (बाइनरी ढूंढना,
बाइनरी प्रोसेस करना, रिपॉज़िटरी में फ़ाइल बनाना या कोई फ़ाइल डाउनलोड करना
इंटरनेट से मिलता है). इसके लिए एपीआई दस्तावेज़ देखें
ज़्यादा जानकारी उपलब्ध कराती है. उदाहरण:
def _impl(repository_ctx):
repository_ctx.symlink(repository_ctx.attr.path, "")
local_repository = repository_rule(
implementation=_impl,
...)
लागू करने का फ़ंक्शन कब चलाया जाता है?
रेपो नियम को लागू करने का फ़ंक्शन तब लागू किया जाता है, जब Baज़ल को डेटा स्टोर करने की उस जगह से टारगेट करता है, उदाहरण के लिए जब कोई दूसरा टारगेट (किसी दूसरे रेपो) उस पर निर्भर करता है या कमांड लाइन पर मौजूद होने पर भी). कॉन्टेंट बनाने इसके बाद, लागू करने वाले फ़ंक्शन को फ़ाइल में रेपो बनाने की उम्मीद होती है सिस्टम. इसे "फ़ेच करना" कहा जाता है और भी बहुत कुछ नहीं कर सकते.
सामान्य लक्ष्यों के उलट, जब डेटा को स्टोर करने की ज़रूरत होती है, तब ही डेटा स्टोर करने की जगह को फिर से फ़ेच करना ज़रूरी नहीं होता. ऐसा तब होता है, जब कुछ ऐसे बदलाव होंगे जिनसे रीपो अलग हो जाएगा. यह है क्योंकि बेज़ल कुछ चीज़ों में हुए बदलावों का पता नहीं लगा पाते या ऐसा करने से वे हर बिल्ड पर बहुत ज़्यादा ओवरहेड करते हैं. उदाहरण के लिए, फ़ेच की जाने वाली चीज़ें नेटवर्क से). इसलिए, डेटा स्टोर करने की जगह को सिर्फ़ तब फिर से फ़ेच किया जाता है, जब इन चीज़ों में बदलाव होता है:
- वे एट्रिब्यूट जिन्हें रेपो नियम को लागू करने के लिए भेजा गया है.
- Starlark कोड में रेपो नियम को लागू करना शामिल है.
repository_ctxके पास भेजे गए किसी भी एनवायरमेंट वैरिएबल की वैल्यू यह तरीकाgetenv()तरीका अपनाया जा सकता है याenvironएट्रिब्यूट के साथ इसका एलान किया गया हैrepository_rule. वैल्यू इन एनवायरमेंट वैरिएबल को कमांड लाइन पर हार्ड-तार वाले--repo_envफ़्लैग करें.read(),execute()और इससे मिलते-जुलते दस्तावेज़ को पास की गई किसी भी फ़ाइल का कॉन्टेंटrepository_ctxका कोई दूसरा तरीका चुनें, जिसे किसी लेबल से बताया गया हो. उदाहरण के लिए,//mypkg:label.txtहै, लेकिनmypkg/label.txtनहीं)bazel fetch --forceशुरू होने पर.
repository_rule के दो पैरामीटर हैं, जो डेटा स्टोर करने की जगह को कब कंट्रोल करते हैं
फिर से फ़ेच किए जाते हैं:
- अगर
configureफ़्लैग सेट किया गया है, तो डेटा स्टोर करने की जगह को सिर्फ़ फिर से फ़ेच किया जाता हैbazel fetchजब--configureपैरामीटर को पास किया जाता है (अगर विशेषता सेट नहीं है, तो इस आदेश से फिर से फ़ेच नहीं होगा) - अगर
localफ़्लैग सेट किया गया है, तो ऊपर दिए गए मामलों के अलावा, रेपो बेज़ल सर्वर के रीस्टार्ट होने पर भी फिर से लाया जाता है.
लागू करने वाले फ़ंक्शन को रीस्टार्ट करना
रेपो की समीक्षा के दौरान, लागू करने वाले फ़ंक्शन को फिर से शुरू किया जा सकता है अनुरोध की गई किसी डिपेंडेंसी के मौजूद नहीं होने पर, फ़ेच की जाती है. इस स्थिति में, लागू करने का फ़ंक्शन बंद हो जाएगा, और जो डिपेंडेंसी मौजूद नहीं है उसे हल किया जाएगा और डिपेंडेंसी हल होने के बाद, फ़ंक्शन फिर से चालू होगा. यहां की यात्रा पर हूं बार-बार रीस्टार्ट होने से बचें. ये महंगे होते हैं, क्योंकि हो सकता है कि नेटवर्क ऐक्सेस करने की कई वजहें हों बार-बार इस्तेमाल करना पड़ता है), तो लेबल के आर्ग्युमेंट प्रीफ़ेच किए जाते हैं, बशर्ते सभी लेबल आर्ग्युमेंट को किसी मौजूदा फ़ाइल में रिज़ॉल्व किया जा सकता है. ध्यान दें कि समाधान करना किसी स्ट्रिंग या लेबल में मौजूद पाथ, जिसे सिर्फ़ एक्ज़ीक्यूशन के दौरान बनाया गया था फ़ंक्शन के इस्तेमाल करने के बाद भी रीस्टार्ट हो सकता है.
डेटा स्टोर की बाहरी जगहों को फिर से फ़ेच करने के लिए
कभी-कभी, बाहरी डेटा स्टोर करने की जगह बिना किसी बदलाव के पुरानी हो सकती है
डेफ़िनिशन या डिपेंडेंसी का इस्तेमाल किया जाता है. उदाहरण के लिए, रेपो फ़ेच करने वाले सोर्स
किसी तीसरे पक्ष के डेटा स्टोर करने की जगह की खास ब्रांच को फ़ॉलो करने पर,
जो बैंक स्टेटमेंट में उपलब्ध है. इस स्थिति में, बेज़ल से सभी को फिर से फ़ेच करने के लिए कहा जा सकता है
बिना किसी शर्त के bazel fetch --force --all पर कॉल करके डेटा स्टोर करें.
इसके अलावा, कुछ रेपो नियम, लोकल मशीन की जांच करते हैं और ये
अगर लोकल मशीन को अपग्रेड किया गया था, तो यह पुराना हो गया है. यहां बेज़ल से ये काम करने के लिए कहा जा सकता है
उन बाहरी डेटा को फिर से लाएं जहां
repository_rule
परिभाषा में configure विशेषता सेट है, तो इसका इस्तेमाल करें
bazel fetch --all --configure.
उदाहरण
C++ अपने-आप कॉन्फ़िगर होने वाला टूलचेन: यह रेपो नियम का इस्तेमाल करता है, ताकि स्थानीय C++ कंपाइलर की खोज करके, बेज़ल के लिए C++ कॉन्फ़िगरेशन फ़ाइलें देखने के लिए, और फ़्लैग, C++ कंपाइलर के साथ काम करते हैं.
डेटा स्टोर करने की जगह पर जाएं डिपेंडेंसी की सूची तय करने के लिए कई
repository_ruleका इस्तेमाल करता है Go के नियमों का इस्तेमाल करना ज़रूरी होता है.rules_jvm_external का इस्तेमाल करके बनाया गया डिफ़ॉल्ट रूप से
@mavenनाम की एक बाहरी डेटा स्टोर करने की जगह, जो बिल्ड टारगेट जनरेट करती है ट्रांज़िटिव डिपेंडेंसी ट्री में हर Maven आर्टफ़ैक्ट के लिए.