सामान्य नियम

नियम

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

उपनाम

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

alias नियम एक और नाम बनाता है, जिसे नियम कहा जा सकता है.

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

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

• अगर कमांड लाइन में उपनाम का इस्तेमाल किया जाता है, तो जांच नहीं की जाती हैं. उपनाम तय करने के लिए जो रेफ़रेंस टेस्ट करता है, test_suite का इस्तेमाल करें नियम, जिसके tests में एक ही टारगेट हो एट्रिब्यूट की वैल्यू सबमिट करें.
• एनवायरमेंट ग्रुप तय करते समय, 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 (या तो साफ़ तौर पर कमांड लाइन पर या सीधे तौर पर .baZZrc फ़ाइलों से):

  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 (या तो साफ़ तौर पर कमांड लाइन पर या सीधे तौर पर .bagelrc फ़ाइलें):

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

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

  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 या सूची का टाइप) इस्तेमाल की जाती हैं Starlark फ़्लैग), 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"] का उत्पादन करते हैं. फ़्लैग की परिभाषाएं देखें और सटीक अनुमान लगाने के लिए, शर्तों को ध्यान से देखें.

• अगर आपको ऐसी स्थितियां तय करनी हैं जिन्हें बिल्ट-इन बिल्ड फ़्लैग से मॉडल नहीं किया गया है, तो स्टारलार्क के बनाए हुए झंडे. --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 गलत है, दायरे से बाहर के टारगेट को सिर्फ़ चेतावनी के साथ छोड़ दिया जाएगा). कॉन्टेंट बनाने ऐसा न हो, यह पक्का करने का सबसे आसान तरीका है कि एक जैसे लेबल बताएं के स्कोप में दिखेगा.

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

जेनक्वेरी के आउटपुट को --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, उपयोगकर्ता के तय किए गए Bash निर्देश का इस्तेमाल करके, एक या उससे ज़्यादा फ़ाइलें जनरेट करता है.

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

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

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

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

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

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

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

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

खास मामले

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

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

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

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

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

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

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

सामान्य सलाह

• यह पक्का करें कि जेनरूल की मदद से चलने वाले टूल डिटरमिनिस्टिक और हर्मेटिक हों. इन्हें नहीं लिखना चाहिए टाइमस्टैंप बहुत अच्छे होते हैं. साथ ही, सेट और मैप के लिए उन्हें स्टेबल क्रम का इस्तेमाल करना चाहिए. आउटपुट के लिए सिर्फ़ मिलते-जुलते फ़ाइल पाथ लिखें, ऐब्सलूट पाथ को नहीं. इस नियम का पालन न करने पर इसकी वजह से उम्मीद के मुताबिक बिल्ड व्यवहार हो जाता है (बेज़ल उस सामान्य नियम को फिर से नहीं बना रहा है जिसके बारे में आपको लगता था) और कैश परफ़ॉर्मेंस में कमी.
• आउटपुट, टूल, और सोर्स के लिए, $(location) का ज़्यादा इस्तेमाल करें. इस वजह से अलग-अलग कॉन्फ़िगरेशन के लिए आउटपुट फ़ाइलों को अलग-अलग कैटगरी में रखें. जेन नियम, हार्ड कोड किए गए कोड का इस्तेमाल नहीं कर सकते और/या ऐब्सलूट पाथ का इस्तेमाल करें.
• अगर समान या बहुत मिलते-जुलते जेन रूल इस्तेमाल किए गए हैं, तो एक सामान्य स्टारलार्क मैक्रो लिखें एक से ज़्यादा जगह पर. अगर जेनरुल जटिल है, तो इसे स्क्रिप्ट में या इस तरह लागू करें: स्टारलार्क नियम. इससे ऐप्लिकेशन को पढ़ना आसान होने के साथ-साथ, टेस्ट करने में आसानी होती है.
• पक्का करें कि एग्ज़िट कोड सही तरीके से यह दिखाता हो कि सामान्य नियम लागू हुआ या नहीं.
• 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).
• सिमलिंक और डायरेक्ट्री बनाने से बचें. Baज़ल, डायरेक्ट्री/सिमलिंक पर कॉपी नहीं होता जेन रूल की मदद से बनाई गई संरचना और डायरेक्ट्री की डिपेंडेंसी की जांच करने वाली जानकारी ठीक नहीं है.
• अन्य नियमों में जेन रूल का रेफ़रंस देते समय, जेनरल के लेबल या अलग-अलग आउटपुट फ़ाइलों के लेबल के साथ. कभी-कभी एक तरीका ज़्यादा पढ़ने लायक होता है, कभी-कभी अन्य: इस्तेमाल करने वाले नियम की srcs में नाम से आउटपुट देने से बचें जेनरूल के दूसरे आउटपुट को अनजाने में चुनना कई आउटपुट देता है.

उदाहरण

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

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

नीचे दिए गए उदाहरण में, filegroup का इस्तेमाल करने का तरीका बताया गया है और एक और genrule के आउटपुट पा सकते हैं. ध्यान दें कि इसके बजाय $(SRCS) का इस्तेमाल किया जा रहा है $(location) डायरेक्टिव का सुझाव भी काम करेगा; इस उदाहरण में बाद वाले उदाहरण का इस्तेमाल दिखाने के लिए किया जा सकता है.

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 जैसे शुरू करने के लिए, Blaze पहले //some/test:suite टारगेट में ट्रांज़िट रूप से शामिल किए गए सभी टेस्ट टारगेट की गणना करता है (हम इसे "test_suite एक्सपैंशन") कॉल करें. इसके बाद, Blaze उन टारगेट को तैयार करके उनकी जांच करता है.

उदाहरण

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

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"],
)

तर्क