कस्टम क्रिया बनाने के लिए मैक्रो का उपयोग करना

Bazel के साथ रोज़ का इंटरैक्शन, मुख्य रूप से कुछ निर्देशों की मदद से होता है: build, test, और run. हालांकि, कभी-कभी ये सीमित लग सकते हैं: हो सकता है कि आपको किसी रिपॉज़िटरी में पैकेज पुश करने हों, असली उपयोगकर्ताओं के लिए दस्तावेज़ पब्लिश करने हों या Kubernetes की मदद से कोई ऐप्लिकेशन डिप्लॉय करना हो. हालांकि, Bazel में publish या deploy कमांड नहीं है – ये कार्रवाइयां कहां फ़िट होती हैं?

bazel run कमांड

Bazel, पूरी तरह से सुरक्षित, दोबारा इस्तेमाल किए जा सकने वाले, और इंक्रीमेंटल कॉन्फ़िगरेशन पर फ़ोकस करता है. इसका मतलब है कि ऊपर दिए गए टास्क के लिए, build और test कमांड काम के नहीं हैं. ये कार्रवाइयां, सीमित नेटवर्क ऐक्सेस वाले सैंडबॉक्स में चल सकती हैं. साथ ही, यह गारंटी नहीं है कि हर bazel build के साथ इन्हें फिर से चलाया जाएगा.

इसके बजाय, bazel run का इस्तेमाल करें: यह उन टास्क के लिए सबसे ज़्यादा काम आता है जिनके लिए आपको साइड इफ़ेक्ट चाहिए. Bazel के उपयोगकर्ता, ऐसे नियमों का इस्तेमाल करते हैं जिनसे प्रोग्राम चलाने लायक फ़ाइलें बनती हैं. साथ ही, नियम बनाने वाले लोग, "कस्टम वर्ब" तक इसे बढ़ाने के लिए, पैटर्न के एक सामान्य सेट का पालन कर सकते हैं.

नियमों के बारे में जानकारी: rules_k8s

उदाहरण के लिए, rules_k8s, Bazel के लिए Kubernetes के नियम. मान लें कि आपका टारगेट यह है:

# BUILD file in //application/k8s
k8s_object(
    name = "staging",
    kind = "deployment",
    cluster = "testing",
    template = "deployment.yaml",
)

जब staging टारगेट पर bazel build का इस्तेमाल किया जाता है, तो k8s_object नियम एक स्टैंडर्ड Kubernetes YAML फ़ाइल बनाता है. हालांकि, अन्य टारगेट भी k8s_object मैक्रो की मदद से बनाए जाते हैं. इन मैक्रो के नाम staging.apply और :staging.delete जैसे होते हैं. ये कार्रवाइयां करने के लिए स्क्रिप्ट बनाई जाती हैं. bazel run staging.apply के साथ इस्तेमाल करने पर, ये स्क्रिप्ट हमारे bazel k8s-apply या bazel k8s-delete निर्देशों की तरह काम करती हैं.

दूसरा उदाहरण: ts_api_guardian_test

यह पैटर्न, Angular प्रोजेक्ट में भी देखा जा सकता है. ts_api_guardian_test मैक्रो से दो टारगेट बनते हैं. पहला, एक स्टैंडर्ड nodejs_test टारगेट है, जो जनरेट किए गए कुछ आउटपुट की तुलना "गोल्डन" फ़ाइल से करता है. इसका मतलब है कि वह फ़ाइल जिसमें उम्मीद के मुताबिक आउटपुट होता है. इसे सामान्य bazel test कॉल के साथ बनाया और चलाया जा सकता है. angular-cli में, bazel test //etc/api:angular_devkit_core_api की मदद से ऐसा एक टारगेट चलाया जा सकता है.

समय के साथ, इस गोल्डन फ़ाइल को मान्य वजहों से अपडेट करना पड़ सकता है. इसे मैन्युअल तरीके से अपडेट करना मुश्किल और गड़बड़ी भरा होता है. इसलिए, यह मैक्रो एक nodejs_binary टारगेट भी उपलब्ध कराता है, जो गोल्डन फ़ाइल की तुलना करने के बजाय उसे अपडेट करता है. एक ही टेस्ट स्क्रिप्ट को "पुष्टि करें" या "स्वीकार करें" मोड में चलाने के लिए लिखा जा सकता है. यह इस बात पर निर्भर करता है कि इसे कैसे शुरू किया गया है. यह उसी पैटर्न का पालन करता है जिसे आपने पहले ही सीख लिया है: इसमें कोई नेटिव bazel test-accept कमांड नहीं है, लेकिन bazel run //etc/api:angular_devkit_core_api.accept का इस्तेमाल करके वही असर पाया जा सकता है.

यह पैटर्न काफ़ी असरदार हो सकता है. इसे पहचानने के बाद, यह काफ़ी सामान्य हो जाता है.

अपने नियमों में बदलाव करना

इस पैटर्न में मैक्रो सबसे अहम होते हैं. मैक्रो का इस्तेमाल नियमों की तरह किया जाता है. हालांकि, ये कई टारगेट बना सकते हैं. आम तौर पर, वे बताए गए नाम के साथ एक टारगेट बनाएंगे, जो मुख्य बिल्ड ऐक्शन करता है: हो सकता है कि यह एक सामान्य बाइनरी, Docker इमेज या सोर्स कोड का संग्रह बनाता हो. इस पैटर्न में, मुख्य टारगेट के आउटपुट के आधार पर साइड इफ़ेक्ट वाली स्क्रिप्ट बनाने के लिए अतिरिक्त टारगेट बनाए जाते हैं. जैसे, नतीजे के तौर पर मिलने वाले बाइनरी को पब्लिश करना या टेस्ट के अनुमानित आउटपुट को अपडेट करना.

इसे दिखाने के लिए, एक काल्पनिक नियम को मैक्रो के साथ Sphinx के साथ जनरेट करें, ताकि एक ऐसा अतिरिक्त टारगेट बनाया जा सके जो उपयोगकर्ता के तैयार होने पर उसे पब्लिश करने की अनुमति देता हो. Sphinx की मदद से वेबसाइट जनरेट करने के लिए, यहां दिए गए मौजूदा नियम का पालन करें:

_sphinx_site = rule(
     implementation = _sphinx_impl,
     attrs = {"srcs": attr.label_list(allow_files = [".rst"])},
)

इसके बाद, इस तरह के नियम पर विचार करें, जो एक स्क्रिप्ट बनाता है. इसे चलाने पर, जनरेट किए गए पेज पब्लिश हो जाते हैं:

_sphinx_publisher = rule(
    implementation = _publish_impl,
    attrs = {
        "site": attr.label(),
        "_publisher": attr.label(
            default = "//internal/sphinx:publisher",
            executable = True,
        ),
    },
    executable = True,
)

आखिर में, ऊपर दिए गए दोनों नियमों के लिए एक साथ टारगेट बनाने के लिए, यह मैक्रो तय करें:

def sphinx_site(name, srcs = [], **kwargs):
    # This creates the primary target, producing the Sphinx-generated HTML.
    _sphinx_site(name = name, srcs = srcs, **kwargs)
    # This creates the secondary target, which produces a script for publishing
    # the site generated above.
    _sphinx_publisher(name = "%s.publish" % name, site = name, **kwargs)

BUILD फ़ाइलों में, मैक्रो का इस्तेमाल इस तरह करें जैसे वह सिर्फ़ मुख्य टारगेट बनाता हो:

sphinx_site(
    name = "docs",
    srcs = ["index.md", "providers.md"],
)

इस उदाहरण में, एक "दस्तावेज़" टारगेट बनाया गया है, जैसे कि मैक्रो एक स्टैंडर्ड, सिंगल बेज़ल नियम था. नियम बनाने पर, वह कुछ कॉन्फ़िगरेशन जनरेट करता है और एचटीएमएल साइट बनाने के लिए Sphinx को चलाता है. यह साइट, मैन्युअल जांच के लिए तैयार होती है. हालांकि, एक और "docs.publish" टारगेट भी बनाया जाता है, जो साइट को पब्लिश करने के लिए स्क्रिप्ट बनाता है. प्राइमरी टारगेट का आउटपुट देखने के बाद, bazel run :docs.publish का इस्तेमाल करके इसे सार्वजनिक तौर पर पब्लिश किया जा सकता है. यह ठीक वैसा ही है जैसे किसी काल्पनिक bazel publish कमांड का इस्तेमाल करना.

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

rules_k8s में, .apply यही काम करता है: expand_template apply.sh.tpl के आधार पर, एक बहुत ही आसान Bash स्क्रिप्ट लिखता है, जो मुख्य टारगेट के आउटपुट के साथ kubectl चलाता है. इसके बाद, इस स्क्रिप्ट को bazel run :staging.apply की मदद से बनाया और चलाया जा सकता है. इसमें k8s_object टारगेट के लिए k8s-apply निर्देश दिया जा सकता है.