กฎทั่วไป

กฎ

• ชื่อแทน
• config_setting
• กลุ่มไฟล์
• genquery
• การสร้างกฎเกณฑ์
• test_suite

ชื่อแทน

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

กฎ alias จะสร้างชื่ออื่นที่อาจเรียกว่ากฎ

ส่วนชื่อแทนจะใช้ได้กับเป้าหมาย "ปกติ" เท่านั้น โดยเฉพาะอย่างยิ่ง ชื่อแทน package_group และ test_suite ไม่ได้

กฎของชื่อแทนมีการประกาศระดับการเข้าถึงของตัวเอง ในด้านอื่นๆ ทั้งหมด กฎจะทำงานเหมือนกับกฎที่อ้างอิง (เช่น ระบบจะไม่สนใจ testonly ในชื่อแทน และจะใช้เพียงการทดสอบเท่านั้นของกฎที่อ้างอิงแทน) โดยมีข้อยกเว้นเล็กน้อยดังต่อไปนี้

• การทดสอบจะไม่ทำงานหากมีการพูดถึงชื่อแทนในบรรทัดคำสั่ง หากต้องการกำหนดชื่อแทนที่เรียกใช้การทดสอบที่อ้างอิง ให้ใช้กฎ 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 โดยสมมติว่ามี constraint_value ที่มีป้ายกำกับ //example:glibc_2_25 อยู่ โปรดทราบว่าแพลตฟอร์มจะยังคงตรงกันหากกำหนดค่าข้อจำกัดเพิ่มเติมที่นอกเหนือจาก 2 ค่านี้

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

Notes

• ดู select สำหรับสิ่งที่จะเกิดขึ้นเมื่อ 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 ทั้ง 2 อย่างจะให้ผลลัพธ์ ["a", "b"] ตรวจสอบคำจำกัดความของแฟล็กและทดสอบเงื่อนไขอย่างรอบคอบเพื่อยืนยันความคาดหวังที่แน่นอน

• หากต้องการกำหนดเงื่อนไขที่ไม่ได้สร้างโมเดลโดยแฟล็กบิลด์ในตัว ให้ใช้ แฟล็กที่ Starlark กำหนด นอกจากนี้คุณยังใช้ --define ได้ด้วย แต่วิธีนี้ทำให้การสนับสนุนไม่ดีนักและไม่แนะนำให้ใช้ ดูการสนทนาเพิ่มเติมที่นี่
• หลีกเลี่ยงการใช้คำจำกัดความ config_setting ที่ซ้ำกันในแพ็กเกจที่ต่างกัน แต่ให้อ้างอิง config_setting ทั่วไปที่กำหนดไว้ในแพ็กเกจ Canonical แทน
• คุณใช้ values, define_values และ constraint_values ร่วมกับชุดค่าผสมใดก็ได้ใน config_setting เดียวกัน แต่ต้องมีการตั้งค่าอย่างน้อย 1 รายการสำหรับ 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 แทนการอ้างอิงไดเรกทอรีโดยตรง เวอร์ชันหลังไม่มีเสียงเนื่องจากระบบบิลด์ไม่มีความรู้ที่สมบูรณ์เกี่ยวกับไฟล์ทั้งหมดที่อยู่ใต้ไดเรกทอรี ระบบจึงสร้างใหม่ไม่ได้เมื่อไฟล์เหล่านี้มีการเปลี่ยนแปลง เมื่อใช้ร่วมกับ glob filegroup จะทำให้ระบบของบิลด์รู้จักไฟล์ทั้งหมดได้อย่างชัดเจน

ตัวอย่าง

หากต้องการสร้าง filegroup ที่ประกอบด้วยไฟล์ต้นฉบับ 2 ไฟล์ ให้ทำ

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

หรือใช้ glob เพื่อค้นหาไดเรกทอรี testdata:

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() เรียกใช้การค้นหาที่ระบุในภาษาของการค้นหา Blaze และดัมพ์ผลลัพธ์ลงในไฟล์

ระบบจะอนุญาตให้การค้นหาเข้าชมการปิดเป้าหมายที่ระบุในแอตทริบิวต์ scope เท่านั้นเพื่อให้บิลด์สอดคล้องกัน การค้นหาที่ละเมิดกฎนี้จะดำเนินการไม่สำเร็จหากไม่ได้ระบุ strict หรือเป็นจริง (หาก strict เป็นเท็จ ระบบจะข้ามเป้าหมายที่อยู่นอกขอบเขตพร้อมแสดงคำเตือน) วิธีที่ง่ายที่สุดที่จะป้องกันปัญหานี้คือการพูดถึงป้ายกำกับเดียวกันในขอบเขตในนิพจน์การค้นหา

ความแตกต่างเพียงอย่างเดียวระหว่างการค้นหาที่อนุญาตที่นี่และในบรรทัดคำสั่งคือคำค้นหาที่มีข้อกำหนดเฉพาะเป้าหมายไวลด์การ์ด (เช่น //pkg:* หรือ //pkg:all) ไม่ได้รับอนุญาตที่นี่ เหตุผลของการค้นหานี้มี 2 แบบ ดังนี้ เนื่องจาก genquery ต้องระบุขอบเขตเพื่อป้องกันไม่ให้เป้าหมายที่อยู่นอกการปิดแบบทรานซิทีฟของการค้นหามีผลต่อผลลัพธ์ และข้อที่ 2 คือเนื่องจากไฟล์ BUILD ไม่รองรับการอ้างอิงไวลด์การ์ด (เช่น ไม่อนุญาต deps=["//a/..."])

เอาต์พุตของ genquery จะเรียงลำดับโดยใช้ --order_output=full เพื่อบังคับใช้เอาต์พุตเชิงกำหนด

ชื่อของไฟล์เอาต์พุตคือชื่อของกฎ

ตัวอย่าง

ตัวอย่างนี้เขียนรายการป้ายกำกับในการปิดทางอ้อมของเป้าหมายที่ระบุไปยังไฟล์

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

อาร์กิวเมนต์

Genrule

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 จะสร้างไฟล์อย่างน้อย 1 ไฟล์โดยใช้คำสั่ง Bash ที่ผู้ใช้กำหนด

กฎเกณฑ์เป็นกฎการสร้างโดยทั่วไปที่คุณสามารถใช้ได้หากไม่มีกฎเฉพาะสำหรับงาน ตัวอย่างเช่น คุณเรียกใช้ Bash 1 บรรทัด อย่างไรก็ตาม หากจำเป็นต้องคอมไพล์ไฟล์ C++ ให้ยึดตามกฎ cc_* ที่มีอยู่ เพราะการดำเนินการที่ยุ่งยากทั้งหมดได้ดำเนินไปให้คุณแล้ว

อย่าใช้ Genrule เพื่อทำการทดสอบ จะมีการชดเชยพิเศษสำหรับการทดสอบและผลการทดสอบ รวมถึงนโยบายการแคชและตัวแปรสภาพแวดล้อม โดยทั่วไปคุณจะต้องดำเนินการทดสอบหลังจากที่บิลด์เสร็จสมบูรณ์และในสถาปัตยกรรมเป้าหมาย ในขณะที่ Genrules จะทำงานระหว่างบิลด์และสถาปัตยกรรมโฮสต์ (ทั้ง 2 แบบอาจแตกต่างกัน) หากต้องการกฎการทดสอบวัตถุประสงค์ทั่วไป ให้ใช้ sh_test

ข้อควรพิจารณาเกี่ยวกับการคอมไพล์ข้าม

ดูข้อมูลเพิ่มเติมเกี่ยวกับการคอมไพล์ข้ามได้ในคู่มือผู้ใช้

ขณะที่ Genrules ทำงานระหว่างบิลด์ เอาต์พุตของมักจะใช้หลังจากบิลด์ สำหรับการทำให้ใช้งานได้หรือการทดสอบ ลองดูตัวอย่างการคอมไพล์โค้ด C สำหรับไมโครคอนโทรลเลอร์ คอมไพเลอร์จะยอมรับไฟล์ต้นฉบับ C และสร้างโค้ดที่ทำงานบนไมโครคอนโทรลเลอร์ แน่นอนว่าโค้ดที่สร้างขึ้นไม่สามารถทำงานบน CPU ที่ใช้ในการสร้างโค้ดได้ แต่ตัวคอมไพเลอร์ C (หากคอมไพล์จากแหล่งที่มา) เองจำเป็นต้องใช้

ระบบบิลด์ใช้การกำหนดค่าโฮสต์เพื่ออธิบายเครื่องที่บิลด์ทำงานและการกำหนดค่าเป้าหมายเพื่ออธิบายเครื่องที่ควรเรียกใช้เอาต์พุตของบิลด์ โดยมีตัวเลือกในการกำหนดค่ารายการเหล่านี้และแยกไฟล์ที่เกี่ยวข้องออกเป็นไดเรกทอรีแยกต่างหากเพื่อหลีกเลี่ยงข้อขัดแย้ง

สำหรับ Genrules ระบบบิลด์จะดูแลให้มีการสร้างทรัพยากร Dependency อย่างเหมาะสมด้วย srcs จะสร้างขึ้น (หากจำเป็น) สำหรับการกำหนดค่าเป้าหมาย, tools สร้างขึ้นสำหรับการกำหนดค่าโฮสต์ และจะถือว่าเอาต์พุตเป็นของการกำหนดค่าเป้าหมาย และยังมี ตัวแปร "สร้าง" ที่คำสั่ง Genrule สามารถส่งผ่านไปยังเครื่องมือที่เกี่ยวข้องได้

โปรดทราบว่า Genrule ไม่ได้ระบุแอตทริบิวต์ deps โดยกฎอื่นๆ ที่มีไว้ให้อยู่แล้วจะใช้ข้อมูลเมตาที่ขึ้นอยู่กับภาษาที่ส่งผ่านระหว่างกฎเพื่อกำหนดวิธีจัดการกฎที่ไม่เชื่อมโยงโดยอัตโนมัติ แต่ระบบอัตโนมัติระดับนี้ไม่สามารถทำได้สำหรับ Genrules การสร้างกฎจะทำงานที่ระดับไฟล์และ Runfiles เท่านั้น

กรณีพิเศษ

การคอมไพล์โฮสต์และโฮสต์: ในบางกรณี ระบบบิลด์จะต้องเรียกใช้ Genrules เพื่อให้สามารถดำเนินการเอาต์พุตระหว่างบิลด์ได้ด้วย เช่น หาก Genrule สร้างคอมไพเลอร์ที่กำหนดเองบางรูปแบบซึ่งหลังจากนั้นมีการใช้โดยเจนอื่น กฎแรกจะต้องสร้างเอาต์พุตสำหรับการกำหนดค่าโฮสต์ เพราะเป็นที่ที่คอมไพเลอร์จะทำงานในอีกรุ่นหนึ่ง ในกรณีนี้ ระบบบิลด์จะทำสิ่งที่ถูกต้องโดยอัตโนมัติ โดยจะสร้าง srcs และ outs ของรุ่นแรกสำหรับการกำหนดค่าโฮสต์แทนการกำหนดค่าเป้าหมาย ดูข้อมูลเพิ่มเติมได้ที่คู่มือผู้ใช้

เครื่องมือ JDK และ C++: หากต้องการใช้เครื่องมือจาก JDK หรือชุดคอมไพเลอร์ C++ ระบบบิลด์จะมีชุดตัวแปรที่จะใช้ ดูรายละเอียดได้ที่ตัวแปร"ผู้ผลิต"

สภาพแวดล้อมการสร้างกฎ

คำสั่ง genrule จะทำงานโดย Bash Shell ที่กำหนดค่าล้มเหลวเมื่อคำสั่งหรือไปป์ไลน์ล้มเหลวโดยใช้ set -e -o pipefail

เครื่องมือบิลด์จะเรียกใช้คำสั่ง Bash ในสภาพแวดล้อมกระบวนการที่ปลอดภัยที่กำหนดเฉพาะตัวแปรหลัก เช่น PATH, PWD, TMPDIR และอื่นๆ ระบบจะไม่ส่งตัวแปรส่วนใหญ่ที่กำหนดไว้ในสภาพแวดล้อม Shell ของผู้ใช้ไปยังคำสั่งของ genrule เพื่อให้มั่นใจว่าบิลด์จะทำซ้ำได้ แต่ Bazel (แต่ไม่ใช่ Blaze) จะส่งผ่านค่าตัวแปรสภาพแวดล้อม PATH ของผู้ใช้ การเปลี่ยนแปลงค่าของ PATH จะทำให้ Bazel เรียกใช้คำสั่งอีกครั้งในบิลด์ถัดไป

คำสั่ง genrule ไม่ควรเข้าถึงเครือข่าย ยกเว้นเพื่อเชื่อมต่อกระบวนการที่เป็นรายการย่อยของคำสั่งเอง แม้ว่าจะยังไม่ได้บังคับใช้ก็ตาม

ระบบบิลด์จะลบไฟล์เอาต์พุตที่มีอยู่โดยอัตโนมัติ แต่จะสร้างไดเรกทอรีระดับบนสุดที่จำเป็นก่อนที่จะเรียกใช้ Genrule และยังนำไฟล์เอาต์พุตออกในกรณีที่เกิดข้อผิดพลาดอีกด้วย

คำแนะนำทั่วไป

• โปรดตรวจสอบว่าเครื่องมือที่เรียกใช้โดยกฎเกณฑ์มีหลักการและมีความครบถ้วนสมบูรณ์ เครื่องมือดังกล่าวไม่ควรเขียนการประทับเวลาลงในเอาต์พุต และควรใช้การจัดลำดับที่เสถียรสำหรับชุดและแผนที่ รวมถึงเขียนเฉพาะเส้นทางไฟล์แบบสัมพัทธ์ไปยังเอาต์พุต ไม่ใช่เส้นทางที่แน่นอน การไม่ปฏิบัติตามกฎนี้จะทำให้เกิดลักษณะการทำงานที่ไม่คาดคิด (Bazel ไม่ได้สร้างกฎเกณฑ์ตามที่คุณคิดไว้ใหม่) และทำให้ประสิทธิภาพของแคชลดลง
• ใช้ $(location) อย่างครอบคลุมสำหรับเอาต์พุต เครื่องมือ และแหล่งที่มา เนื่องจากการแยกไฟล์เอาต์พุตสำหรับการกำหนดค่าที่ต่างกัน ทำให้ Genrules ไม่สามารถพึ่งพาเส้นทางแบบฮาร์ดโค้ดและ/หรือเส้นทางแบบสัมบูรณ์
• ควรเขียนมาโคร Starlark ทั่วไปในกรณีที่มีการใช้กฎ Gen เดียวกันหรือคล้ายกันมากในหลายๆ ที่ หาก Genrule มีความซับซ้อน ให้พิจารณาติดตั้งใช้งานในสคริปต์หรือใช้เป็นกฎ 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 และการตรวจสอบการอ้างอิงของไดเรกทอรีจะไม่เกิดขึ้น
• เมื่ออ้างอิง Genrule ในกฎอื่นๆ คุณจะใช้ป้ายกำกับของกฎเกณฑ์หรือป้ายกำกับของไฟล์เอาต์พุตแต่ละไฟล์ก็ได้ ในบางครั้งวิธีหนึ่งอาจอ่านได้ง่ายกว่า แต่บางวิธี เช่น การอ้างอิงเอาต์พุตตามชื่อใน srcs ของกฎการใช้จะหลีกเลี่ยงการเลือกเอาต์พุตอื่นๆ ของ GenRule โดยไม่ได้ตั้งใจ แต่อาจเป็นเรื่องน่าเบื่อหาก Genrule สร้างเอาต์พุตจำนวนมาก

ตัวอย่าง

ตัวอย่างนี้สร้าง foo.h ไม่มีแหล่งที่มา เนื่องจากคำสั่งไม่ได้ป้อนข้อมูลใดๆ "ไบนารี" ที่เรียกใช้โดยคำสั่งเป็นสคริปต์ Perl ในแพ็กเกจเดียวกับ Genrule

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

อาร์กิวเมนต์