सामान्य नियम

नियम

• दूसरा ईमेल पता
• config_setting
• फ़ाइल ग्रुप
• जनरेट करने के लिए क्वेरी
• जेनरूल
• test_suite

उपनाम

alias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)

alias नियम की मदद से एक और नाम बनाया जा सकता है, जिसे दूसरे नियम के तौर पर इस्तेमाल किया जा सकता है.

एलियासिंग सिर्फ़ "सामान्य" टारगेट के लिए काम करती है. खास तौर पर, package_group और test_suite को उपनाम नहीं दिया जा सकता.

उपनाम नियम की अपनी खुद की 'किसे दिखे' घोषणा होती है. अन्य सभी मामलों में, यह इसके बताए गए नियम की तरह काम करता है (उदाहरण के लिए, उपनाम पर सिर्फ़ टेस्ट करने की सुविधा को अनदेखा किया जाता है; इसकी जगह, बताए गए नियम की सिर्फ़ टेस्ट-ओनलीनेस का इस्तेमाल किया जाता है) कुछ छोटे अपवादों के साथ:

• अगर कमांड लाइन पर उनके उपनाम का ज़िक्र होता है, तो जांच नहीं की जाती हैं. रेफ़र किए गए टेस्ट को चलाने वाला उपनाम तय करने के लिए, उसके tests एट्रिब्यूट में एक टारगेट वाले test_suite नियम का इस्तेमाल करें.
• एनवायरमेंट ग्रुप तय करते समय, environment नियमों के लिए उपनाम काम नहीं करते. ये --target_environment कमांड लाइन विकल्प में भी काम नहीं करते.

उदाहरण

filegroup(
    name = "data",
    srcs = ["data.txt"],
)

alias(
    name = "other",
    actual = ":data",
)

तर्क

config_setting

config_setting(name, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, tags, testonly, values, visibility)

कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट को ट्रिगर करने के लिए, यह कॉन्फ़िगरेशन की सही स्थिति (इसे बिल्ड फ़्लैग या प्लैटफ़ॉर्म कंस्ट्रेंट के तौर पर दिखाया जाता है) से मैच करता है. इस नियम का इस्तेमाल करने के तरीके के बारे में जानने के लिए, चुनें और सामान्य सुविधा की खास जानकारी के लिए, कॉन्फ़िगर किए जा सकने वाले एट्रिब्यूट देखें.

उदाहरण

नीचे दिया गया, उस बिल्ड से मैच करता है जो --compilation_mode=opt या -c opt को सेट करता है (या तो कमांड लाइन पर या साफ़ तौर पर .bazelrc फ़ाइलों से):

  config_setting(
      name = "simple",
      values = {"compilation_mode": "opt"}
  )
  

नीचे दिया गया तरीका, ARM को टारगेट करने वाले किसी भी बिल्ड से मैच करता है और कस्टम परिभाषित FOO=bar (जैसे, bazel build --cpu=arm --define FOO=bar ...) को लागू करता है:

  config_setting(
      name = "two_conditions",
      values = {
          "cpu": "arm",
          "define": "FOO=bar"
      }
  )
  

नीचे दिया गया तरीका, उपयोगकर्ता के तय किए गए फ़्लैग --//custom_flags:foo=1 को सेट करने वाले किसी भी बिल्ड से मिलता-जुलता है (या तो साफ़ तौर पर कमांड लाइन पर या .bazelrc फ़ाइलों से किसी और तरीके से):

  config_setting(
      name = "my_custom_flag_is_set",
      flag_values = { "//custom_flags:foo": "1" },
  )
  

नीचे दिया गया तरीका, x86_64 आर्किटेक्चर और glibc के वर्शन 2.25 वाले प्लैटफ़ॉर्म को टारगेट करने वाले किसी भी बिल्ड से मैच करता है. हालांकि, यह मानते हुए कि //example:glibc_2_25 लेबल वाला constraint_value मौजूद है. ध्यान रखें कि कोई प्लैटफ़ॉर्म तब भी मैच करता है, जब वह अतिरिक्त कंस्ट्रेंट वैल्यू के बारे में बताता है.

  config_setting(
      name = "64bit_glibc_2_25",
      constraint_values = [
          "@platforms//cpu:x86_64",
          "//example:glibc_2_25",
      ]
  )
  

ज़रूरी जानकारी

• यह देखने के लिए चुनें देखें कि जब एक से ज़्यादा config_setting, कॉन्फ़िगरेशन की मौजूदा स्थिति से मैच करते हैं, तो क्या होता है.
• शॉर्टहैंड फ़ॉर्म (जैसे, --compilation_mode बनाम -c) के साथ काम करने वाले फ़्लैग के लिए, values परिभाषाओं में फ़ुल फ़ॉर्म का इस्तेमाल किया जाना चाहिए. इनमें से किसी भी फ़ॉर्म का इस्तेमाल करके, बातचीत शुरू करने वाली भाषाओं का अपने-आप मिलान हो जाता है.
• अगर किसी फ़्लैग में एक से ज़्यादा वैल्यू (जैसे, --copt=-Da --copt=-Db या सूची वाला टाइप स्टारलार्क फ़्लैग) होती हैं, तो values = { "flag": "a" } तब मैच करता है, जब असल सूची में किसी भी जगह मौजूद हो."a"

  values = { "myflag": "a,b" } इसी तरह काम करता है: यह --myflag=a --myflag=b, --myflag=a --myflag=b --myflag=c, --myflag=a,b, और --myflag=c,b,a से मेल खाता है. हर फ़्लैग के लिए सटीक सिमैंटिक अलग-अलग होते हैं. उदाहरण के लिए, --copt एक ही इंस्टेंस में एक से ज़्यादा वैल्यू के साथ काम नहीं करता: --copt=a,b ["a,b"] जनरेट करता है, जबकि --copt=a --copt=b से ["a", "b"] जनरेट होता है (इसलिए, values = { "copt": "a,b" } पुरानी वैल्यू से मैच करता है, लेकिन बाद वाली वैल्यू से नहीं). हालांकि, --ios_multi_cpus (Apple के नियमों के लिए) -ios_multi_cpus=a,b और ios_multi_cpus=a --ios_multi_cpus=b , दोनों ["a", "b"] बनाते है. फ़्लैग की परिभाषाएं जांचें और अपनी शर्तों की सावधानी से जांच करें, ताकि आपको सही उम्मीद हो.

• अगर आपको ऐसी शर्तें तय करनी हैं जिन्हें पहले से मौजूद बिल्ड फ़्लैग से मॉडल नहीं किया गया है, तो Starlark के तय किए गए फ़्लैग इस्तेमाल करें. आपके पास --define का इस्तेमाल करने का भी विकल्प है. हालांकि, इससे कम सहायता मिलती है. इसलिए, हम ऐसा करने का सुझाव नहीं देते हैं. ज़्यादा चर्चा के लिए, यहां जाएं.
• अलग-अलग पैकेज में एक जैसी config_setting परिभाषाओं को दोहराने से बचें. इसके बजाय, कैननिकल पैकेज में बताए गए एक सामान्य config_setting का रेफ़रंस दें.
• values, define_values, और constraint_values को एक ही config_setting में किसी भी कॉम्बिनेशन में इस्तेमाल किया जा सकता है. हालांकि, किसी भी config_setting के लिए कम से कम एक को सेट करना ज़रूरी है.

तर्क

            config_setting(
                name = "a_and_b",
                values = {
                    "define": "a=1",
                    "define": "b=2",
                })
          

            config_setting(
                name = "a_and_b",
                define_values = {
                    "a": "1",
                    "b": "2",
                })
          

फ़ाइलग्रुप

filegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)

टारगेट के कलेक्शन को एक आसान नाम देने के लिए, filegroup का इस्तेमाल करें. इसके बाद, इनकी जानकारी दूसरे नियमों से ली जा सकती है.

सीधे डायरेक्ट्री बताने के बजाय, filegroup का इस्तेमाल करने की सलाह दी जाती है. बाद वाली गड़बड़ी ठीक नहीं होती, क्योंकि बिल्ड सिस्टम के पास डायरेक्ट्री में मौजूद सभी फ़ाइलों की पूरी जानकारी नहीं होती. इसलिए, हो सकता है कि इन फ़ाइलों में बदलाव होने पर, वह फिर से न बने. ग्लोब के साथ इस्तेमाल करने पर, filegroup यह पक्का कर सकता है कि सभी फ़ाइलें साफ़ तौर पर बिल्ड सिस्टम को पता हों.

उदाहरण

दो सोर्स फ़ाइलों वाला filegroup बनाने के लिए, यह करें

filegroup(
    name = "mygroup",
    srcs = [
        "a_file.txt",
        "some/subdirectory/another_file.txt",
    ],
)

इसके अलावा, टेस्टडेटा डायरेक्ट्री को इकट्ठा करने के लिए, glob का इस्तेमाल करें:

filegroup(
    name = "exported_testdata",
    srcs = glob([
        "testdata/*.dat",
        "testdata/logs/**/*.log",
    ]),
)

इन परिभाषाओं का इस्तेमाल करने के लिए, filegroup में किसी भी नियम के लेबल के साथ रेफ़रंस दें:

cc_library(
    name = "my_library",
    srcs = ["foo.cc"],
    data = [
        "//my_package:exported_testdata",
        "//my_package:mygroup",
    ],
)

तर्क

Genquery

genquery(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, expression, features, licenses, opts, restricted_to, scope, strict, tags, target_compatible_with, testonly, visibility)

genquery(), ब्लेज़ क्वेरी भाषा में तय की गई क्वेरी चलाता है और नतीजे को एक फ़ाइल में डाल देता है.

बिल्ड को एक जैसा बनाए रखने के लिए, क्वेरी की अनुमति सिर्फ़ scope एट्रिब्यूट में बताए गए टारगेट के पूरी तरह से बंद होने वाले पेज पर जाने की अनुमति है. अगर strict सही नहीं है या strict सही नहीं है, तो इस नियम का उल्लंघन करने वाली क्वेरी को लागू नहीं किया जा सकेगा (अगर strict गलत है, तो दायरे से बाहर के टारगेट को स्किप कर दिया जाएगा). ऐसा न हो, यह पक्का करने का सबसे आसान तरीका यह है कि दायरे में उन लेबल के बारे में बताएं जो क्वेरी एक्सप्रेशन में हैं.

यहां और कमांड लाइन के लिए, इस्तेमाल की जा सकने वाली क्वेरी के बीच अंतर सिर्फ़ यह है कि यहां वाइल्डकार्ड टारगेट से जुड़ी जानकारी (जैसे, //pkg:* या //pkg:all) वाली क्वेरी की अनुमति नहीं है. इसकी वजहें दो-फ़ोल्ड हैं: पहला, क्योंकि genquery को एक स्कोप तय करना होता है, ताकि क्वेरी के ट्रांज़िटिव क्लोज़र से बाहर के टारगेट को रोका जा सके, ताकि इसके आउटपुट पर असर पड़ सके. दूसरा, क्योंकि BUILD फ़ाइलें, वाइल्डकार्ड डिपेंडेंसी के साथ काम नहीं करतीं (जैसे, deps=["//a/..."] की अनुमति नहीं है).

डिटर्मिनिस्टिक आउटपुट को लागू करने के लिए, genquery के आउटपुट को --order_output=full का इस्तेमाल करके ऑर्डर किया जाता है.

आउटपुट फ़ाइल का नाम, नियम का नाम होता है.

उदाहरण

यह उदाहरण, किसी फ़ाइल के लिए तय किए गए टारगेट के ट्रांज़िटिव क्लोज़ में लेबल की सूची लिखता है.

genquery(
    name = "kiwi-deps",
    expression = "deps(//kiwi:kiwi_lib)",
    scope = ["//kiwi:kiwi_lib"],
)

तर्क

जेनरूल

genrule(name, srcs, outs, cmd, cmd_bash, cmd_bat, cmd_ps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exec_tools, executable, features, licenses, local, message, output_licenses, output_to_bindir, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)

genrule, उपयोगकर्ता के तय किए गए बैश कमांड का इस्तेमाल करके, एक या उससे ज़्यादा फ़ाइलें जनरेट करता है.

जेन रूल, सामान्य बिल्ड नियम होते हैं. इनका इस्तेमाल तब किया जा सकता है, जब टास्क के लिए कोई खास नियम न हो. उदाहरण के लिए, बैश वन-लाइनर चलाया जा सकता है. अगर आपको C++ फ़ाइलें कंपाइल करनी हैं, तो cc_* के मौजूदा नियमों का पालन करें. इसकी वजह यह है कि आपने सभी मुश्किल काम पहले ही कर लिए हैं.

टेस्ट चलाने के लिए जेनरूल का इस्तेमाल न करें. जांच और जांच के नतीजों के लिए खास शर्तें होती हैं. इनमें कैश मेमोरी में सेव करने की नीतियां और एनवायरमेंट वैरिएबल भी शामिल हैं. आम तौर पर, टेस्ट, बिल्ड पूरा होने के बाद और टारगेट आर्किटेक्चर पर किए जाते हैं. जबकि, जनरेटर, बिल्ड और होस्ट आर्किटेक्चर के दौरान चलाए जाते हैं (दोनों अलग-अलग हो सकते हैं). अगर आपको अलग-अलग कामों के लिए इस्तेमाल किए जाने वाले टेस्टिंग नियम की ज़रूरत है, तो sh_test का इस्तेमाल करें.

क्रॉस-कंपाइलेशन ध्यान देने वाली बातें

क्रॉस-कंप्यूलेशन के बारे में ज़्यादा जानकारी के लिए, इस्तेमाल के लिए गाइड देखें.

जनरेट होने के दौरान, जनरेट किए गए जेनरूल काम करते हैं. हालांकि, उनके आउटपुट का इस्तेमाल आम तौर पर बिल्ड के बाद, डिप्लॉयमेंट या टेस्टिंग के लिए किया जाता है. माइक्रोकंट्रोलर के लिए C कोड को कंपाइल करने का उदाहरण देखें: कंपाइलर, C सोर्स फ़ाइलों को स्वीकार करता है और माइक्रोकंट्रोलर पर चलने वाला कोड जनरेट करता है. जनरेट किया गया कोड उस सीपीयू पर नहीं चल सकता जिसका इस्तेमाल इसे बनाने के लिए किया गया था. हालांकि, सी कंपाइलर (अगर सोर्स से कंपाइल किया गया हो) खुद ही ऐसा कर सकता है.

बिल्ड सिस्टम, होस्ट कॉन्फ़िगरेशन का इस्तेमाल उन मशीन की जानकारी देने के लिए करता है जिन पर बिल्ड चलता है. साथ ही, टारगेट कॉन्फ़िगरेशन का इस्तेमाल उस मशीन (इन) की जानकारी देने के लिए किया जाता है जिस पर बिल्ड का आउटपुट चलना चाहिए. यह इनमें से हर एक को कॉन्फ़िगर करने के विकल्प देता है और यह संबंधित फ़ाइलों को अलग-अलग डायरेक्ट्री में बांट देता है, ताकि कोई टकराव न हो.

जनरेटिव सिस्टम के लिए, बिल्ड सिस्टम यह पक्का करता है कि डिपेंडेंसी सही तरीके से बनाई गई हो: टारगेट कॉन्फ़िगरेशन के लिए srcs बनाए गए हों (अगर ज़रूरी हो), tools, होस्ट कॉन्फ़िगरेशन के लिए बनाए गए हों, और आउटपुट टारगेट कॉन्फ़िगरेशन के लिए बनाया गया हो. इससे "Make" वैरिएबल भी मिलते हैं, जिन्हें जनरेट करने वाले निर्देश, उनसे जुड़े टूल को पास कर सकते हैं.

यह जान-बूझकर किसी deps एट्रिब्यूट के बारे में नहीं बताता है: पहले से मौजूद अन्य नियम, नियमों के बीच पास की गई भाषा पर आधारित मेटा जानकारी का इस्तेमाल करते हैं. इससे यह अपने-आप तय होता है कि डिपेंडेंट नियमों को कैसे मैनेज किया जाए. हालांकि, जनरेट करने के नियमों के लिए, ऑटोमेशन का यह लेवल संभव नहीं है. जेनरूल पूरी तरह से फ़ाइल और रनफ़ाइल लेवल पर काम करते हैं.

खास मामले

होस्ट-होस्ट को कंपाइल करना: कुछ मामलों में, बिल्ड सिस्टम को जनरेट करने के नियम इस तरह चलाने की ज़रूरत होती है कि बिल्ड के दौरान आउटपुट भी लागू किया जा सके. उदाहरण के लिए, अगर कोई जेनरूल कुछ कस्टम कंपाइलर बनाता है जिसे बाद में कोई दूसरा जेनरूल इस्तेमाल करता है, तो पहले वाले को होस्ट कॉन्फ़िगरेशन के लिए आउटपुट देना होता है, क्योंकि इसी जगह पर कंपाइलर दूसरे जेनरूल में चलेगा. इस मामले में, बिल्ड सिस्टम सही काम अपने-आप करता है: यह, टारगेट कॉन्फ़िगरेशन के बजाय, होस्ट कॉन्फ़िगरेशन के लिए पहले जेनरूल के srcs और outs को बनाता है. ज़्यादा जानकारी के लिए, इस्तेमाल के लिए गाइड देखें.

JDK और C++ टूलिंग: JDK या C++ कंपाइलर सुइट के टूल का इस्तेमाल करने के लिए, बिल्ड सिस्टम इस्तेमाल करने के लिए वैरिएबल का एक सेट उपलब्ध कराता है. ज़्यादा जानकारी के लिए, "बनाएं" वैरिएबल देखें.

जेनरूल एनवायरमेंट

जेनरूल निर्देश, बैश शेल के ज़रिए लागू किया जाता है. इसे set -e -o pipefail का इस्तेमाल करके, किसी निर्देश या पाइपलाइन के काम न करने पर कॉन्फ़िगर किया जाता है.

बिल्ड टूल, सैनिटाइज़्ड प्रोसेस एनवायरमेंट में बैश कमांड एक्ज़ीक्यूट करता है. यह सिर्फ़ PATH, PWD, TMPDIR, और कुछ अन्य जैसे कोर वैरिएबल के बारे में बताता है. यह पक्का करने के लिए कि बिल्ड फिर से बनाए जा सकें, उपयोगकर्ता के शेल एनवायरमेंट में तय किए गए ज़्यादातर वैरिएबल, जेनरूल के निर्देश के ज़रिए पास नहीं किए जाते. हालांकि, Bazel (हालांकि, Blaze नहीं) उपयोगकर्ता के PATH के एनवायरमेंट वैरिएबल की वैल्यू से गुज़रता है. PATH की वैल्यू में कोई भी बदलाव करने पर, Bazel अगले बिल्ड पर निर्देश को फिर से लागू कर देगा.

जेनरूल निर्देश को नेटवर्क को ऐक्सेस नहीं करना चाहिए. हालांकि, उसे उन प्रोसेस से कनेक्ट करने के लिए ऐक्सेस करना चाहिए जो कमांड के बच्चे हों. हालांकि, फ़िलहाल इसे लागू नहीं किया गया है.

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

सामान्य सलाह

• यह पक्का करें कि जेनरूल की मदद से चलाए जा रहे टूल, डिटर्मिनिस्टिक और हेमेटिक हों. उन्हें अपने आउटपुट में टाइमस्टैंप नहीं लिखने चाहिए. साथ ही, उन्हें सेट और मैप के लिए, स्टेबल क्रम का इस्तेमाल करना चाहिए. साथ ही, उन्हें आउटपुट के लिए सिर्फ़ मिलते-जुलते फ़ाइल पाथ, बिना किसी ऐब्सलूट पाथ को लिखना चाहिए. इस नियम का पालन न करने पर, उम्मीद के मुताबिक बिल्ड बिहेवियर होगा (बज़ल आपके हिसाब से जेनरूल दोबारा नहीं बना पाएगा) और कैश मेमोरी की परफ़ॉर्मेंस में कमी आएगी.
• आउटपुट, टूल, और सोर्स के लिए, $(location) का ज़्यादा से ज़्यादा इस्तेमाल करें. अलग-अलग कॉन्फ़िगरेशन के लिए आउटपुट फ़ाइलों को अलग-अलग किए जाने की वजह से, जनरेटिव एआई, हार्ड कोड और/या ऐब्सलूट पाथ पर भरोसा नहीं कर सकता.
• एक सामान्य Starlark मैक्रो लिखें, ताकि कई जगहों पर एक जैसे या बहुत मिलते-जुलते जनरेट का इस्तेमाल होने पर आसानी से उसका इस्तेमाल किया जा सके. अगर जेनरूल मुश्किल है, तो इसे स्क्रिप्ट या स्टारलार्क नियम के तौर पर लागू करें. इससे पढ़ने और टेस्ट करने में आसानी होती है.
• पक्का करें कि एग्ज़िट कोड, जेनरूल की सफलता या असफलता को सही तरीके से दिखाता हो.
• stdout या stderr पर जानकारी देने वाले मैसेज न लिखें. हालांकि, यह डीबग करने के लिए काम का है, लेकिन यह आसानी से ग़ैर-ज़रूरी डेटा बन सकता है. इसलिए, जनरेटिव जनरेट होने की प्रोसेस पूरी तरह से सटीक नहीं होनी चाहिए. दूसरी ओर, अगर कोई सफल जेनरूल काम नहीं करता, तो उससे अच्छी गड़बड़ी के मैसेज मिलने चाहिए.
• $$ evaluates to a $, a literal dollar-sign, so in order to invoke a shell command containing dollar-signs such as ls $(dirname $x), one must escape it thus: ls $$(dirname $$x).
• सिमलिंक और डायरेक्ट्री बनाने से बचें. Bazel, Genrules की मदद से बनाई गई डायरेक्ट्री/सिमलिंक के स्ट्रक्चर को कॉपी नहीं करता. साथ ही, डायरेक्ट्री की डिपेंडेंसी की जांच में गड़बड़ी हुई है.
• दूसरे नियमों में जेनरूल का रेफ़रंस देते समय, जेनरूल के लेबल का या अलग-अलग आउटपुट फ़ाइलों के लेबल का इस्तेमाल किया जा सकता है. कभी-कभी एक तरीका ज़्यादा पढ़ा जा सकता है, कभी-कभी दूसरा तरीका: इस्तेमाल करने वाले नियम के srcs में आउटपुट को नाम से इस्तेमाल करने से, अनजाने में जनरेट किए गए नियम के दूसरे आउटपुट का इस्तेमाल करने से बचा जा सकता है. हालांकि, अगर जेनरूल से कई आउटपुट जनरेट होते हैं, तो यह काफ़ी मुश्किल हो सकता है.

उदाहरण

इस उदाहरण से, foo.h जनरेट होता है. कोई सोर्स नहीं है, क्योंकि निर्देश कोई इनपुट नहीं लेता. निर्देश से चलाई जाने वाली "बाइनरी", पर्ल स्क्रिप्ट होती है. यह उसी पैकेज में होती है जिसमें जेनरूल होता है.

genrule(
    name = "foo",
    srcs = [],
    outs = ["foo.h"],
    cmd = "./$(location create_foo.pl) > \"$@\"",
    tools = ["create_foo.pl"],
)

इस उदाहरण में, filegroup को इस्तेमाल करने का तरीका और दूसरे genrule के आउटपुट के बारे में बताया गया है. ध्यान दें कि साफ़ तौर पर $(location) के बजाय, $(SRCS) का इस्तेमाल करने से भी फ़ायदा होगा. यह उदाहरण, जानकारी देने के लिए बाद वाले निर्देश का इस्तेमाल करता है.

genrule(
    name = "concat_all_files",
    srcs = [
        "//some:files",  # a filegroup with multiple files in it ==> $(locations)
        "//other:gen",   # a genrule with a single output ==> $(location)
    ],
    outs = ["concatenated.txt"],
    cmd = "cat $(locations //some:files) $(location //other:gen) > $@",
)

तर्क

test_suite

test_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, tests, visibility)

test_suite, टेस्ट के ऐसे सेट के बारे में बताता है जो इंसानों के लिए "काम का" माने जाते हैं. इससे प्रोजेक्ट को टेस्ट के सेट तय करने में मदद मिलती है. जैसे, "चेक-इन से पहले आपको किए जाने वाले टेस्ट", "हमारे प्रोजेक्ट के स्ट्रेस टेस्ट" या "सभी छोटे टेस्ट." blaze test कमांड, इस तरह के संगठन का पालन करता है: blaze test //some/test:suite जैसे कहने के लिए, ब्लेज़ पहले //some/test:suite टारगेट में शामिल सभी टेस्ट टारगेट की गिनती करता है (हम इसे "test_suite एक्सपैंशन" भी कहते हैं). इसके बाद, ब्लेज़ उन टारगेट को बनाता और उनकी जांच करता है.

उदाहरण

एक टेस्ट सुइट, जो मौजूदा पैकेज में सभी छोटे टेस्ट को चलाता है.

test_suite(
    name = "small_tests",
    tags = ["small"],
)

एक टेस्ट सुइट, जो चुनिंदा टेस्ट सेट करता है:

test_suite(
    name = "smoke_tests",
    tests = [
        "system_unittest",
        "public_api_unittest",
    ],
)

मौजूदा पैकेज में सभी टेस्ट चलाने के लिए एक टेस्ट सुइट. यह सुविधा अस्थिर नहीं है.

test_suite(
    name = "non_flaky_test",
    tags = ["-flaky"],
)

तर्क