डिप्लॉयमेंट के नियम

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.
किसी समस्या की शिकायत करें स्रोत देखें

यह पेज उन नियम लेखकों के लिए है जो अपने नियम अन्य लोगों के लिए उपलब्ध कराने का प्लान बना रहे हैं.

होस्टिंग और नाम रखने के नियम

नए नियम आपके संगठन के तहत अपने GitHub डेटा संग्रह स्थान में जाने चाहिए. अगर आपको लगता है कि आपके नियम bazelbuild संगठन में हैं, तो bazel-dev की ईमेल पाने वाले लोगों की सूची से संपर्क करें.

Bazel के नियमों के लिए रिपॉज़िटरी के नाम, इस फ़ॉर्मैट में दिए गए हैं: $ORGANIZATION/rules_$NAME. GitHub पर उदाहरण देखें. अपने बेज़ल नियमों को प्रकाशित करते समय, आपको एक जैसे फ़ॉर्मैट का पालन करना होगा.

ब्यौरे की जानकारी देने वाले GitHub के डेटा स्टोर करने की जगह का ब्यौरा और README.md शीर्षक का इस्तेमाल करें:

  • रिपॉज़िटरी का नाम: bazelbuild/rules_go
  • डेटा स्टोर करने की जगह का ब्यौरा: Bzel के नियमों पर जाएं
  • रिपॉज़िटरी टैग: golang, bazel
  • README.md हेडर: Bazel के नियमों पर जाएं (https://bazel.build के लिंक पर ध्यान दें, जो Bazel से अनजान उपयोगकर्ताओं को सही जगह पर ले जाएगा)

नियमों को भाषा (जैसे कि स्काला) या प्लैटफ़ॉर्म (जैसे कि Android) के हिसाब से ग्रुप में बांटा जा सकता है.

डेटा स्टोर करने की जगह

हर नियम के डेटा स्टोर करने की जगह का एक खास लेआउट होना चाहिए, ताकि उपयोगकर्ता तेज़ी से नए नियमों को समझ सकें.

उदाहरण के लिए, mockascript (मेक-मानें) भाषा के लिए नए नियम लिखते समय, नियम डेटा संग्रह में इस तरह का स्ट्रक्चर होगा:

/
  LICENSE
  README
  WORKSPACE
  mockascript/
    constraints/
      BUILD
    runfiles/
      BUILD
      runfiles.mocs
    BUILD
    defs.bzl
  tests/
    BUILD
    some_test.sh
    another_test.py
  examples/
    BUILD
    bin.mocs
    lib.mocs
    test.mocs

Workspace

प्रोजेक्ट के WORKSPACE में, आपको वह नाम तय करना होगा, जिसका इस्तेमाल करके उपयोगकर्ता आपके नियमों का संदर्भ देंगे. अगर आपके नियम bazelbuild संगठन से संबंधित हैं, तो आपको rules_<lang> (जैसे कि rules_mockascript) का इस्तेमाल करना होगा. नहीं तो, आपको अपने डेटा स्टोर करने की जगह <org>_rules_<lang> (जैसे build_stack_rules_proto) का नाम देना चाहिए. अगर आपको लगता है कि आपके नियम bazelbuild संगठन में नियमों के लिए पालन किए जाने चाहिए, तो कृपया bazel-dev की ईमेल पाने वाले लोगों की सूची से संपर्क करें.

नीचे दिए गए सेक्शन में, यह मान लें कि डेटा स्टोर करने की जगह bazelbuild संगठन से जुड़ी है.

workspace(name = "rules_mockascript")

README

सबसे ऊपर के स्तर पर, README को शामिल किया जाना चाहिए. इसमें कम से कम यह होना चाहिए कि उपयोगकर्ताओं को आपके नियम का इस्तेमाल करने के लिए, WORKSPACE फ़ाइल में चिपकाने के लिए क्या करना होगा. आम तौर पर, यह http_archive आपकी GitHub रिलीज़ की ओर संकेत करेगा. साथ ही, यह एक ऐसा मैक्रो कॉल है जो आपके नियम के लिए ज़रूरी सभी टूल को डाउनलोड/कॉन्फ़िगर करता है. उदाहरण के लिए, Go नियम के लिए, यह ऐसा दिखता है:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "rules_go",
    urls = ["https://github.com/bazelbuild/rules_go/releases/download/0.18.5/rules_go-0.18.5.tar.gz"],
    sha256 = "a82a352bffae6bee4e95f68a8d80a70e87f42c4741e6a448bec11998fcc82329",
)
load("@rules_go//go:deps.bzl", "go_rules_dependencies", "go_register_toolchains")
go_rules_dependencies()
go_register_toolchains()

अगर आपके नियम, डेटा स्टोर करने के किसी दूसरे नियम पर निर्भर हैं, तो इसकी जानकारी नियमों के दस्तावेज़ में दें (उदाहरण के लिए, Skydoc के नियम, जो Sass नियमों पर निर्भर हैं), और एक WORKSPACE मैक्रो दें जो सभी डिपेंडेंसी डाउनलोड करेगा (ऊपर rules_go देखें).

नियम

आम तौर पर, आपको डेटा स्टोर करने की जगह से जुड़े कई नियम दिखेंगे. भाषा के नाम वाली डायरेक्ट्री बनाएं और एंट्री पॉइंट दें - सभी नियमों को एक्सपोर्ट करने वाली defs.bzl फ़ाइल (इसमें BUILD फ़ाइल भी शामिल करें, ताकि डायरेक्ट्री पैकेज हो). rules_mockascript के लिए इसका मतलब है कि mockascript नाम की एक डायरेक्ट्री होगी और उसमें BUILD फ़ाइल और defs.bzl फ़ाइल होगी:

/
  mockascript/
    BUILD
    defs.bzl

कंस्ट्रेंट

अगर आपका नियम टूलचेन नियमों को तय करता है, तो हो सकता है कि आपको कस्टम constraint_setting और/या constraint_value के बारे में बताना पड़े. इन्हें एक //<LANG>/constraints पैकेज में रखें. आपकी डायरेक्ट्री का स्ट्रक्चर कुछ ऐसा दिखेगा:

/
  mockascript/
    constraints/
      BUILD
    BUILD
    defs.bzl

सबसे सही तरीकों के बारे में जानने के लिए, कृपया github.com/bazelbuild/platforms पढ़ें और पता लगाएं कि कौनसी कंस्ट्रेंट पहले से मौजूद हैं. साथ ही, अगर वे इंडिपेंडेंट हों, तो भाषा की शर्तें समझने में मदद करें. ध्यान रखें कि कस्टम शर्तें लागू करते समय, आपके नियमों के सभी उपयोगकर्ता उनका इस्तेमाल अपनी BUILD फ़ाइलों में प्लैटफ़ॉर्म के हिसाब से लॉजिक करने के लिए करेंगे (उदाहरण के लिए, select का इस्तेमाल करके). कस्टम कंस्ट्रेंट की मदद से, आपको ऐसी भाषा के बारे में पता चलता है जो पूरे बेज़ल नेटवर्क में आती है.

रनफ़ाइल लाइब्रेरी

अगर आपका नियम, रनफ़ाइल को ऐक्सेस करने के लिए कोई स्टैंडर्ड लाइब्रेरी देता है, तो वह //<LANG>/runfiles (//<LANG>/runfiles:runfiles का एक छोटा नाम) पर मौजूद लाइब्रेरी टारगेट के रूप में होना चाहिए. जिन उपयोगकर्ताओं के डेटा को उसकी डिपेंडेंसी ऐक्सेस करने की ज़रूरत होती है वे आम तौर पर, इस टारगेट को deps एट्रिब्यूट में जोड़ देते हैं.

रिपॉज़िटरी के नियम

डिपेंडेंसी

आपके नियमों में बाहरी निर्भरता हो सकती है. अपने नियमों को आसान बनाने के लिए, कृपया WORKSPACE मैक्रो दें, जो उन डिपेंडेंसी पर निर्भरता का एलान करे. जांच के लिए किसी डिपेंडेंसी का एलान न करें. यह सिर्फ़ डिपेंडेंसी के लिए ज़रूरी है. डेवलपमेंट डिपेंडेंसी WORKSPACE फ़ाइल में डालें.

<LANG>/repositories.bzl नाम की फ़ाइल बनाएं और rules_<LANG>_dependencies नाम का एक एंट्री पॉइंट डालें. हमारी डायरेक्ट्री इस तरह दिखेगी:

/
  mockascript/
    constraints/
      BUILD
    BUILD
    defs.bzl
    repositories.bzl

टूलचेन रजिस्टर करना

आपके नियम टूलचेन को भी पंजीकृत कर सकते हैं. कृपया एक अलग WORKSPACE मैक्रो दें, जिसमें इन टूलचेन को रजिस्टर किया गया हो. इस तरह से उपयोगकर्ता पिछले मैक्रो को हटाने और डिपेंडेंसी को मैन्युअल रूप से कंट्रोल करने का फ़ैसला ले सकते हैं. साथ ही, टूलचेन को रजिस्टर कर सकते हैं.

इसलिए, <LANG>/repositories.bzl फ़ाइल में rules_<LANG>_toolchains नाम का WORKSPACE मैक्रो जोड़ें.

ध्यान दें कि विश्लेषण के चरण में टूलचेन का समाधान करने के लिए, बेज़ल को रजिस्टर किए गए सभी toolchainटारगेट का विश्लेषण करना होगा. Bazel को toolchain.toolchain एट्रिब्यूट में बताए गए सभी टारगेट का विश्लेषण करने की ज़रूरत नहीं है. अगर टूलचेन को रजिस्टर करने के लिए, आपको रिपॉज़िटरी में कॉम्प्लेक्स कंप्यूटिंग का काम करना होगा, तो डेटा स्टोर करने की जगह को toolchain टारगेट के साथ <LANG>_toolchain टारगेट के साथ बांट दें. पहले वाली सूची हमेशा फ़ेच की जाएगी, और बाद वाला विकल्प सिर्फ़ तब फ़ेच किया जाएगा, जब इस्तेमाल करने वाले को वाकई <LANG> कोड बनाना होगा.

रिलीज़ स्निपेट

अपनी रिलीज़ की घोषणा में ऐसा स्निपेट दें जिसे आपके उपयोगकर्ता अपनी WORKSPACE फ़ाइल में कॉपी करके चिपका सकें. यह स्निपेट आम तौर पर इस तरह दिखेगा:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "rules_<LANG>",
    urls = ["<url_to_the_release.zip"],
    sha256 = "4242424242",
)
load("@rules_<LANG>//<LANG>:repositories.bzl", "rules_<LANG>_dependencies", "rules_<LANG>_toolchains")
rules_<LANG>_dependencies()
rules_<LANG>_toolchains()

जांच

जांच होनी चाहिए, ताकि पुष्टि हो सके कि नियम उम्मीद के मुताबिक काम कर रहे हैं या नहीं. यह नियम उस भाषा के स्टैंडर्ड स्पेस में हो सकता है जिसके लिए नियम हैं. इसके अलावा, यह टॉप लेवल पर tests/ डायरेक्ट्री भी हो सकती है.

उदाहरण (ज़रूरी नहीं)

उपयोगकर्ताओं के लिए एक examples/ डायरेक्ट्री होना फ़ायदेमंद होता है, जो उपयोगकर्ताओं को कुछ ऐसे बुनियादी तरीके दिखाता है जिनसे नियमों का इस्तेमाल किया जा सकता है.

टेस्ट करना

अपने शुरू करने वाले दस्तावेज़ में बताए गए तरीके से ट्रैविस सेट अप करें. इसके बाद, नीचे दिए गए कॉन्टेंट के साथ, .travis.yml को अपने डेटा स्टोर करने की जगह में जोड़ें:

dist: xenial  # Ubuntu 16.04

# On trusty (or later) images, the Bazel apt repository can be used.
addons:
  apt:
    sources:
    - sourceline: 'deb [arch=amd64] http://storage.googleapis.com/bazel-apt stable jdk1.8'
      key_url: 'https://bazel.build/bazel-release.pub.gpg'
    packages:
    - bazel

script:
  - bazel build //...
  - bazel test //...

अगर आपका डेटा स्टोर करने की जगह bazelbuild संगठन में है, तो इसे ci.bazel.build में जोड़ने के लिए कहें.

दस्तावेज़

अपने नियमों पर टिप्पणी करने के तरीके से जुड़े निर्देशों के लिए स्टारडॉक दस्तावेज़ देखें, ताकि दस्तावेज़ अपने आप जनरेट हो सकें.

अक्सर पूछे जाने वाले सवाल

हम Bazel GitHub के डेटा स्टोर करने की मुख्य जगह में अपना नियम क्यों नहीं जोड़ सकते?

हम Bazel की रिलीज़ से जुड़े नियमों को हटाना चाहते हैं. यह साफ़ हो गया है कि निजी नियम किसके पास हैं. इससे Bazel डेवलपर पर दबाव कम हो जाता है. हमारे उपयोगकर्ताओं के लिए, डिकोडिंग से नियम में बदलाव करना, अपग्रेड करना, डाउनग्रेड करना और बदलना आसान हो जाता है. नियमों में योगदान देने पर, Bazel में योगदान देने की तुलना में, वज़न कम हो सकता है. इसमें नियमों के मुताबिक, इससे जुड़े GitHub डेटा स्टोर करने की जगह का पूरा ऐक्सेस भी शामिल होता है. Bazel का ऐक्सेस सबमिट करने की प्रक्रिया में, बहुत प्रक्रिया शामिल है.

इस वजह से, हमारे उपयोगकर्ताओं को ऐप्लिकेशन इंस्टॉल करने के लिए एक बार और मुश्किल प्रोसेस करनी पड़ती है: उन्हें अपनी WORKSPACE फ़ाइल में, किसी नियम को कॉपी करके उसे चिपकाना होगा, जैसा कि ऊपर दिए गए README.md सेक्शन में दिखाया गया है.

पहले हम Bazel के डेटा स्टोर करने की जगह (//tools/build_rules या //tools/build_defs से कम) पर सभी नियम लागू करते थे. हालांकि, हमने अब भी कुछ नियम बनाए हैं, लेकिन बाकी बचे नियमों को लागू करने पर काम किया जा रहा है.