सामान्य नियम

नियम

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

• अगर आपको ऐसी शर्तें तय करनी हैं जिन्हें पहले से मौजूद बिल्ड फ़्लैग से मॉडल नहीं किया गया है, तो 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(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/..."] की अनुमति नहीं है).

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

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

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

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

खास मामले

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

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

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

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

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

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

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

सामान्य सलाह

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

तर्क